From ancp-bounces@ietf.org Fri Aug 10 15:07:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJZpm-000553-Br; Fri, 10 Aug 2007 15:07:42 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IJZpk-00054v-U0 for ancp-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 15:07:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJZpk-00054n-KT for ancp@ietf.org; Fri, 10 Aug 2007 15:07:40 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJZpj-00051Z-Bx for ancp@ietf.org; Fri, 10 Aug 2007 15:07:40 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Aug 2007 21:07:37 +0200 X-IronPort-AV: i="4.19,245,1183327200"; d="scan'208"; a="150321844:sNHT48955614" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7AJ7au4032184; Fri, 10 Aug 2007 21:07:36 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7AJ7ax0005673; Fri, 10 Aug 2007 19:07:36 GMT Received: from lwood-wxp01.cisco.com (ams3-vpn-dhcp192.cisco.com [10.61.64.192]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id UAA16585; Fri, 10 Aug 2007 20:07:35 +0100 (BST) Message-Id: <200708101907.UAA16585@cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 10 Aug 2007 20:07:32 +0100 To: "Wojciech Dec \(wdec\)" , From: Lloyd Wood Subject: Re: [ANCP] IETF 69 ANCP meeting minutes In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Authentication-Results: ams-dkim-2; header.From=L.Wood@surrey.ac.uk; dkim=neutral X-Spam-Score: -4.0 (----) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Jari Arkko X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org I've archived a copy of the slides and draft for extending ANCP at: http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-floreani-ancp-wireless/ ANCP could be one way to communicate a modem's varying speed to the router a hop along via simple information reports, but, given that this applies ANCP outside of its trusted headend domain, there are probably a lot of (unfounded?) security concerns about crossing the divide of ownership I suppose that the problem of communicating varying link speeds to a connected upstream/downstream router needs to be solved for DSL in general somehow by the DSL forum -- and then that method, whatever it is, could then be generalised beyond DSL to work for other modem technologies. It's certainly not a problem central to ANCP or this workgroup. cheers, L. [..] >15 mins - Extension of ANCP for Satellite and Terrestrial Wireless Modem >Networks - Lloyd Wood (lwood@cisco.com) >http://www.ietf.org/internet-drafts/draft-floreani-ancp-wireless-00.txt > >Been dealing with problem with which ANCP can help >Smart adaptive modems need to update routers with current satellite >modem speed. Similar to DSL. > >Looking at adding wireless class extension to ANCP. > >Point-multipoint and point-point cases. Eventually moving to point to >point. > >Use ethernet between modem and router because of cost. Serial would be >best option, but not going to happen. > >ANCP works across TCP. Given that satellite delay is an issue, doing >ANCP local looks like the answer. > >Multicast CAC use-case also of interest to satellite. > >Interested in comments and whether this is something for ANCP. > >Francois : Seems to match what ANCP does. But isn't it overkill to use >GSMP based protocol just to sync line rate? > >Lloyd : This may be overkill, but we have working code and it will work. >Just software. However a lot of framework is not used. But in deployment >scenarios the fuller framework may get used to cover other access types. > >Sanjay: ANCP between NAS and modem - ok. But ANCP between CPE and modem >raises questions. Is CPE trusted device? ANCP is typically contained to >trusted domain > >Discussion on managed CPE options. Are CPE and NAS operated by different >companies. > >Lloyd: Depends on provider. 50/50 case in satellite industry; some >provide router+modem, others only modem. > >Lloyd: Modems turning to L3 device, part of the problem. Is ANCP >suitable. > >Woj: Do you have specific issues with the protocol spec for satellite >use? > >Lloyd: ANCP is an overkill, but it has all we need. Fine for our use. > >More discussion on CPE side aspect of modem and router. >In DSL case there appears to be the same problem on the home side, >between router and modem. Problem seems to be applicable to DSL too. > >Woj: So far we focused on the service provider side, not the home. Home >is an un-explored area for us. > >Wojciech : Broader question is how do we ensure extensibility of ANCP to >other technologies? Current text protocol spec to be very DSL tech type >centric. Need to decouple function from tech type so that it can be >re-used by other tech types. >Also need to define extensibility path for TLVs. > >Sanjay: For each tech type do we need enumerate the TLVs? > >Woj: No. > >Usual search for blue sheets... _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Aug 27 03:21:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPYug-0005zT-79; Mon, 27 Aug 2007 03:21:30 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IPYug-0005yz-0d for ancp-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 03:21:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPYub-0005yi-GZ for ancp@ietf.org; Mon, 27 Aug 2007 03:21:25 -0400 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPYua-0004Qe-LZ for ancp@ietf.org; Mon, 27 Aug 2007 03:21:25 -0400 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l7R7Kx8p021819 for ; Mon, 27 Aug 2007 09:20:59 +0200 Received: from [172.31.131.203] ([172.31.131.203]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Mon, 27 Aug 2007 09:21:22 +0200 Message-ID: <46D27B70.3060201@alcatel-lucent.be> Date: Mon, 27 Aug 2007 09:21:20 +0200 From: Stefaan DE CNODDER User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2007 07:21:22.0911 (UTC) FILETIME=[DF0C06F0:01C7E87A] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Subject: [ANCP] comments on draft-ietf-ancp-protocol-01 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi, I have a number of comments on draft-ietf-ancp-protocol-01: 1) There are some inconsistencies in terminology with the framework document: The framework talks about CPE and HGW while the protocol draft uses the terms DSL modem, RG, and subscriber devices (see fig.1). Best to allign with the framework document. Also in section 4.5, second paragraph the term CPE is used while this is called the HGW in the framework document and in the framework, CPE means something else. 2) although the draft is not anymore based on draft-ietf-gsmp-v3-base-spec but on RFC 3292 instead, it is still using a number of extensions defined in that draft, which do not make sense anymore: 2a) Tech type in section 5.4.1.1: tech type 1-4 were defined in draft-ietf-gsmp but not in RFC 3292 so it makes no sense in saying that these are already in use by other technologies. Just make them reserved. Also tech type 0xff is not in use by the base spec (which is RFC 3292). 2b) Message format on page 24: The "block length" field was defined in draft-ietf-gsmp but not in RFC 3292. Since this field is only 1 byte and not sufficient for ANCP, the ANCP protocol draft defines a new length field of 2 bytes. Since the GSMP draft does not exist anymore, it makes no sense in keeping the original 1-byte "block length" field. Better to call this 1-byte field now "Reserved" 2c) The X-Function field on page 32 is not used by ANCP and is also not defined by RFC 3292. It looks better to me to use the original GSMP message format in this case by using a 2 byte Function field. 2d) Like the message on page 24, also the message format on page 32 has a 1-byte Block length field that is better renamed to "Reserved". 3) Section 5.2 says that the pType field should be set to 0. Is this also the case when partitions are used? The framework mentions partitions and I believe the protocols spec should support partitions as well. 4) Section 5.3: ANCP should be extensible to support multiple technologies but I do not see how the capability message can be extended with multiple technologies because it looks that only 1 techtype can be put in the message. Is it the intention that when there is a second technogoly, then there are 2 independent capability negotiations (with 2 different messages? This comment does not apply to other messages because for instance in a PORT UP, there will always only be 1 technology. 5) Related to bulk transaction messages: 5a) For the bulk transaction message, what should be the result if 1 message fails? I guess the whole bulk message would fail but is there a specific code for it? 5b) can PORT UP or DOWN messages also be part of a bulk transaction? And what about OAM? I believe the bulk transaction is only for Line configuration messages? 6) For line configuration, an unknown TLV is to be ignored. Would it not be better for these TLVs to have a result field per TLV such that the NAS knows which configuration is done, and which not? For PORT UP it is not relevant because the AN does not have to know what the NAS is doing with the information but for line configuration this looks different. 7) action 0x8 defined in section 5.4.3 is already in use by RFC 3292 8) The IANA considerations section looks incomplete to me: 8a) Besides of defining new numbers for Tech-type, ..., also a complete new name space has to be defined and maintained by IANA. 8b) the name spaces for result field and code field should be modified because ANCP is changing the length of these fields, and hence also the numbers that can be assigned for it. The name spaces "failure response message" and "Result type" have to be redefined. 8c) 0x81 failure code to be assigned by IANA, also the OAM codes. Some minor comments: - section 3.1, second paragrah, first sentence: replace "Access Network" by "Access Aggregation Network" to be in line with figure 1. - section 5, page 15: : "However, the usage of these messages by ANCP, along with relevant modifications and extensions required by ANCP, are described in sections 5.3, 5.4.1, 5.4.2 and 5.4.3 of this document." -> also section 5.4.4 defines extensions. Better to change this into Section 5.4. - why are the Access-Loop-Circuit-ID limited to 63 bytes? And why is "upto 63 bytes" put between brackets? regards, Stefaan _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Aug 28 05:13:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPx8u-0004Qc-4F; Tue, 28 Aug 2007 05:13:48 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IPx8t-0004QX-Kz for ancp-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 05:13:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPx8t-0004QP-BL for ancp@ietf.org; Tue, 28 Aug 2007 05:13:47 -0400 Received: from wip-cdc-wd.wipro.com ([203.91.201.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPx8q-0004x1-Lr for ancp@ietf.org; Tue, 28 Aug 2007 05:13:47 -0400 Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 062C1180AE for ; Tue, 28 Aug 2007 14:44:04 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-cdc-wd.wipro.com (Postfix) with ESMTP id E25E4180A6 for ; Tue, 28 Aug 2007 14:44:03 +0530 (IST) Received: from BLR-EC-MBX03.wipro.com ([10.201.50.161]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Aug 2007 14:44:19 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [ANCP] Comments on draft-ietf-ancp-framework-02 Date: Tue, 28 Aug 2007 14:44:19 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-ietf-ancp-framework-02 Thread-Index: AcfpU83pE3C2QWNARiyqWPyvXPBW3A== From: To: X-OriginalArrivalTime: 28 Aug 2007 09:14:19.0656 (UTC) FILETIME=[D0B70080:01C7E953] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14278aea5bdd1edf35ec09ffb7b61f9d X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0360711965==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0360711965== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E953.D0B7C048" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E953.D0B7C048 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Sven et al., =20 Please find below my comments on ANCP protocol framework draft. Covers most of the sections of the framework draft and points to specific improvements required. =20 Page 6: =20 >From figure 1, it appears that the controller would reside in NAS generally. Not sure if a one-directional controller-reporter model would be the best possible mechanism. This needs to take into account the possibility of extending this mechanism to US QoS control. With the new evolving access model and architecture, possibility of more user-generated content and highbandwidth streams are foreseen, moving away from a provider-centric model. It would help to have provisions for this, by having the control at either endpoints of ANCP adjacency. =20 Page 7: =20 Reporting and/or enforcement function - Here enforcement should probably be a separate function as it can be in AN or NAS. e.g. In NAS traffic shaping based on access loop rate report, the enforcement function is in NAS. Also, enforcement should be based on a policy decision or report. Hence, port testing initiation may not be classified as an example of enforcement. =20 Page 8: =20 2.2.2 - The term NID may be replaced with a term consistent with the figure (HGW). More important than the protocol encapsulations, I think, is the physical layer technologies that may be used in access loop, i.e. different DSL types: ADSL2+, VDSL2, VDSL, SHDSL, etc. (Assuming that this draft considers just DSL as explained in introduction and not WiMAX or PON based access networks) =20 2.2.3 - Paragraph 4 - Enforcement need not be in access node alone (e.g. traffic shaping in NAS) =20 Page 12: =20 3.1 - Section title - could be along the lines of "Access node capabilities report", there seems to be no discovery involved. Paragraph 2 - "topology of the access network" can be removed - it seems to me that NAS does not have any knowledge of the network topology. If needed, it can be addressed in a separate section -Access topology discovery. =20 Paragraph 3 - Reference to "Access port discovery" - needs to be made consistent with section title. =20 Paragraph 5 - Not sure if NAS hierarchical scheduling based on DSL sync rate would be the best possible thing to do. It may help to some extent. But, ANs typically apply rate limiting per DSL port that may be far too lower than the actual DSL sync rate. In such a case, it would make sense to communicate the lesser of the two (sync rate or rate limit). This again may not take into account the bandwidth consumed by multicast traffic replicated locally at AN. =20 Paragraph 6 - Access loop characteristics - Would be a good idea to add DSL port bonding status. If ports are bonded at PHY level or at ATM or ethernet level, it is important that NAS is aware of this to determine the rate for shaping. =20 Page 15: =20 3.2 Access loop configuration - It would be useful to make the result of configuration always communicated back to NAS/controller. This is needed to ensure synchronization between the elements as a configuration may fail or may be denied by an AN. =20 Paragraph 4 - QoS profile for an access loop - it would be good to have an example profile and/or an illustration of this as it is an important functionality. =20 Page 18: =20 4.1 - A requirement is needed to specify the bandwidth limit for protocol message overhead. (ANCP protocol message overhead must not exceed x% of link capacity or x kbps). =20 Page 20: =20 4.4 - ANCP transport requirements - Redundant paths (VLAN/VC) for the control channel can be made a requirement. =20 Page 21: =20 4.5.1 - Last requirement - "AN should be able to work with redundant controllers" - Elaborate on requirement for maintaining redundant adjacencies and the failover mechanisms. =20 Page 22: =20 4.5.2 - ANCP capability negotiation procedure - framework and rationale for this needs to be provided separately. =20 Page 23: =20 4.6.1 - Minimum/maximum number of ANCP adjacencies to be supported by NAS needs to be identified. Number of ANCP instances supported at NAS can also be specified. =20 Page 28: =20 6. - Management related requirements - When ANCP adjacency is up in AN, any configuration parameter successfully updated by ANCP should not be allowed to be changed by local EMS. This is required to ensure consistency of data and operation. =20 A general comment: =20 On using the AN uplink attributes in ANCP, it might be necessary to consider other bottlenecks in aggregation network. The links between AN and NAS could be a direct-connect in which case, it is straightforwad. However, when there are aggregation elements involved, it would help to provide for extensions in the framework to identify any link bottleneck. The capacity of links between aggregation elements or the links betweek an aggregation node and NAS can be static or dynamic (link aggregation). Identifying bottlenecks in the link capacity here would help do a more accurate traffic scheduling or shaping at NAS as compared to having just the AN uplink attributes. =20 Thanks, Kirubaharan ------_=_NextPart_001_01C7E953.D0B7C048 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hello = Sven et=20 al.,
 
Please = find below my=20 comments on ANCP protocol framework draft.
Covers = most of the=20 sections of the framework draft and points to specific improvements=20 required.
 
Page=20 6:
 
From = figure 1, it=20 appears that the controller would reside in NAS = generally.
Not = sure if a=20 one-directional controller-reporter model would be the best possible=20 mechanism.  This needs to take into account the possibility of = extending this mechanism to US QoS control. With the new evolving access = model=20 and architecture, possibility of more user-generated content and = highbandwidth=20 streams are foreseen, moving away from a provider-centric model. It = would help=20 to have provisions for this, by having the control at either endpoints = of ANCP=20 adjacency.
 
Page=20 7:
 
Reporting and/or=20 enforcement function - Here enforcement should probably be a separate = function=20 as it can be in AN or NAS.
e.g. = In NAS traffic=20 shaping based on access loop rate report, the enforcement function is in = NAS.
Also, = enforcement=20 should be based on a policy decision or report. Hence, port testing = initiation=20 may not be classified as an example of enforcement.
 
Page=20 8:
 
2.2.2 = - The term NID=20 may be replaced with a term consistent with the figure (HGW). More = important=20 than the protocol encapsulations, I think, is the physical=20 layer
technologies that=20 may be used in access loop, i.e. different DSL types: ADSL2+, VDSL2, = VDSL,=20 SHDSL, etc. (Assuming that this draft considers just DSL as explained in = introduction and not WiMAX or PON based access = networks)
 
2.2.3 = -=20 Paragraph 4 - Enforcement need not be in access node alone = (e.g.=20 traffic shaping in NAS)
 
Page=20 12:
 
3.1 - = Section title=20 - could be along the lines of "Access node capabilities report", there = seems to=20 be no discovery involved.
Paragraph 2 -=20 "topology of the access network" can be removed - it seems to me that = NAS does=20 not have any knowledge of the network topology.
If = needed, it can be=20 addressed in a separate section -Access topology = discovery.
 
Paragraph 3 -=20 Reference to "Access port discovery" - needs to be made consistent with = section=20 title.
 
Paragraph 5 - Not=20 sure if NAS hierarchical scheduling based on DSL sync rate would be the = best=20 possible thing to do. It may help to some extent.
But, = ANs typically=20 apply rate limiting per DSL port that may be far too lower than the = actual DSL=20 sync rate. In such a case, it would make sense to communicate the lesser of = the two (sync=20 rate or rate limit). This again may not take into account the bandwidth = consumed=20 by multicast traffic replicated locally at AN.
 
Paragraph 6 - Access=20 loop characteristics - Would be a good idea to add DSL port bonding = status. If=20 ports are bonded at PHY level or at ATM or ethernet = level,
it is = important that=20 NAS is aware of this to determine the rate for = shaping.
 
Page=20 15:
 
3.2 = Access loop=20 configuration - It would be useful to make the result of configuration = always=20 communicated back to NAS/controller. This is needed to ensure = synchronization=20 between the elements as a configuration may fail or may be denied by an=20 AN.
 
Paragraph 4 - QoS=20 profile for an access loop - it would be good to have an example profile = and/or=20 an illustration of this as it is an important = functionality.
 
Page=20 18:
 
4.1 - = A requirement=20 is needed to specify the bandwidth limit for protocol message=20 overhead.
(ANCP = protocol=20 message overhead must not exceed x% of link capacity or x=20 kbps).
 
Page=20 20:
 
4.4 - = ANCP transport=20 requirements - Redundant paths (VLAN/VC) for the control channel can be = made a=20 requirement.
 
Page=20 21:
 
4.5.1 = - Last=20 requirement - "AN should be able to work with redundant controllers" - = Elaborate=20 on requirement for maintaining redundant adjacencies and the failover=20 mechanisms.
 
Page=20 22:
 
4.5.2 = - ANCP=20 capability negotiation procedure - framework and rationale for this = needs to be=20 provided separately.
 
Page=20 23:
 
4.6.1 = -=20 Minimum/maximum number of ANCP adjacencies to be supported by NAS needs = to be=20 identified. Number of ANCP instances supported at NAS can also be=20 specified.
 
Page=20 28:
 
6. - = Management=20 related requirements - When ANCP adjacency is up in AN, any = configuration=20 parameter successfully updated by ANCP should not be allowed to be = changed by=20 local EMS. This is required to ensure consistency of data and=20 operation.
 
A = general=20 comment:
 
On = using the AN=20 uplink attributes in ANCP, it might be necessary to consider other = bottlenecks=20 in aggregation network. The links between AN and NAS could be a = direct-connect=20 in which case, it is straightforwad. However, when there are aggregation = elements involved, it would help to provide for extensions in the = framework to=20 identify any link bottleneck. The capacity of links between aggregation = elements=20 or the links betweek an aggregation node and NAS can be static or = dynamic (link=20 aggregation). Identifying bottlenecks in the link capacity here would = help do a=20 more accurate traffic scheduling or shaping at NAS as compared to having = just=20 the AN uplink attributes.
 
Thanks,
Kirubaharan
------_=_NextPart_001_01C7E953.D0B7C048-- --===============0360711965== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============0360711965==--