From mailman-bounces@core3.amsl.com Fri Feb 1 05:48:53 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794B128C91A for ; Fri, 1 Feb 2008 05:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riZjMfO0+NgA for ; Fri, 1 Feb 2008 05:47:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 942DB293C36 for ; Fri, 1 Feb 2008 05:23:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ancp-archive@optimus.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:04:12 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/ancp/ancp-archive%40optimus.ietf.org From mailman-bounces@core3.amsl.com Fri Feb 1 05:50:29 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FED828D6C7 for ; Fri, 1 Feb 2008 05:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQNid1sigABR for ; Fri, 1 Feb 2008 05:46:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9427628CED8 for ; Fri, 1 Feb 2008 05:23:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ancp-archive@optimus.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:04:11 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/ancp/ancp-archive%40optimus.ietf.org From ancp-bounces@ietf.org Sun Feb 3 02:58:47 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88F4E3A6C07; Sun, 3 Feb 2008 02:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.427 X-Spam-Level: X-Spam-Status: No, score=-0.427 tagged_above=-999 required=5 tests=[AWL=-1.429, BAYES_50=0.001, HTML_MESSAGE=1, MIME_HTML_MOSTLY=0.001] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKWYBy9-J4Zh; Sun, 3 Feb 2008 02:58:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DCEA3A6C41; Sun, 3 Feb 2008 02:58:44 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069CE3A6C4A for ; Sun, 3 Feb 2008 02:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJuaQ+xOxe-s for ; Sun, 3 Feb 2008 02:58:40 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [61.144.161.53]) by core3.amsl.com (Postfix) with ESMTP id 7B6F53A6C5C for ; Sun, 3 Feb 2008 02:58:09 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JVN00KINT7I5G@szxga01-in.huawei.com> for ancp@ietf.org; Sun, 03 Feb 2008 18:59:42 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JVN001O3T7H6E@szxga01-in.huawei.com> for ancp@ietf.org; Sun, 03 Feb 2008 18:59:41 +0800 (CST) Received: from z24109b ([10.70.76.86]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JVN0007LT7GYP@szxml04-in.huawei.com> for ancp@ietf.org; Sun, 03 Feb 2008 18:59:41 +0800 (CST) Date: Sun, 03 Feb 2008 18:59:39 +0800 From: Tina TSOU To: Maglione Roberta , Francois Le Faucheur IMAP , OOGHE Sven Message-id: <018601c86653$dfb5a000$564c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <7168964CAC5C144685272595141B6DBA1EC3F1@FRVELSMBS22.ad2.ad.alcatel.com> <47A0B490.2040605@alcatel-lucent.be> <7168964CAC5C144685272595141B6DBA233C10@FRVELSMBS22.ad2.ad.alcatel.com> Cc: ancp@ietf.org Subject: Re: [ANCP] ANCP Multicast Admission Control X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 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="===============1986659688==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1986659688== Content-type: multipart/alternative; boundary="Boundary_(ID_d4griPtYVOnSpC9upYPWWw)" This is a multi-part message in MIME format. --Boundary_(ID_d4griPtYVOnSpC9upYPWWw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Sven, Francois et al, Sorry not replying earlier. I was chairing ITU-T Q.5/11 meeting in Seoul last week, and am in Shenzhen now, and will spend my Spring Festival holidays in Korea next week without internet access. I would let Roberta to reply further if needed:) We support Sven's texts. Minor refinement might be needed. Thanks for all your good comments:) Please see my comments below in line demarked with [Tina: ...]. B. R. Tina ----- Original Message ----- From: OOGHE Sven To: Francois Le Faucheur IMAP ; Tina TSOU ; Maglione Roberta Cc: ancp@ietf.org Sent: Thursday, January 31, 2008 8:19 PM Subject: RE: [ANCP] ANCP Multicast Admission Control Hi Francois, For clarification: The text concerning PS-->AN and PS-->NAS-->AN interactions is based on the proposal sent by Tina and Roberta in http://www1.ietf.org/mail-archive/web/ancp/current/msg00446.html. At that point in time, there was no feedback on the proposal yet. I see you have concerns with the approach. Tina or Roberta, can you share your point of view? Regards, Sven -----Original Message----- From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] Sent: donderdag 31 januari 2008 12:37 To: DE CNODDER Stefaan Cc: Francois Le Faucheur IMAP; OOGHE Sven; ancp@ietf.org Subject: Re: [ANCP] ANCP Multicast Admission Control Hi Stefaan, On 30 Jan 2008, at 18:32, Stefaan DE CNODDER wrote: > > Francois, > >> In addition, it is not clear to me how useful these additional models >> are. It also raises a number of questions. For example, if the Policy >> Server wants to query the AN, should it do so via the NAS instead of >> directly to AN? [Tina: Some slight preference is to via the NAS, as there are many ANs. Via NAS may reduce the connections. From the point of view of AN, it may like single interface to NAS rather than one interface to NAS and the other interface to PS.] > > Both are possible, is there any preferred way according to you? > > Also, to be able to perform complete Video CAC, the AN >> would have to maintain user policy information (eg what is the >> fraction of line bandwidth that can be used for Video for that >> subscriber at that point in time considering the current DSL train >> rate). Is this in line with current ANCP model? [Tina: Raising this scenario is to implement unciast CAC through ANCP. AN only maintains bandwidth information, no user policy information.] >> how is user info made available to AN? [Tina: In AN or PS, manually configure multicast and unicast user bandwidth.] >> What impact does all this have on ANCP? [Tina: No impact. It expand the ANCP scenario, ANCP can support unicast/multicast CAC.] >> While we can start discussing those questions and the usefulness of >> such a model, IMHO this should not delay progress of current ANCP >> documents. >> So in short, I do _not_ support the additional text below relating to >> the introduction of the new additional model (PS-->NAS-->AN) and >> corresponding additional ANCP requirements. > > does this mean that you prefer PS-->AN? No. I am not expressing any preference for PS-->AN over PS-->NAS-->AN There seemed to be a lot of additional text proposed below relating to PS-->NAS-->AN as this involves ANCP more heavily. And I am simply stating that I do not support adding such text. The current framework defines PS-->AN and PS-->NAS-->AN as out of scope for now ("It is therefore beyond the scope of this document.") and I recommend we do not change scope at this stage if we want to have a first version of the ANCP protocol in the targeted timeframe. Those can always be easily added to the scope/protocol once there is stronger consensus/understanding or their applicability in the group and when the WG has completed the first base protocol spec. Francois > To be honest, for me both options are valid. Is there any specific > reason why you would not like to have the request going to the NAS? > > regards, > Stefaan > > >> Cheers >> Francois >> On 28 Jan 2008, at 14:18, OOGHE Sven wrote: >>> Hi, >>> >>> Based on the discussion on the list, I have prepared the following >>> text proposal concerning multicast conditional access. I tried to >>> cover the different scenarios that were identified on the list. This >>> includes the proposal from Tina and Roberta, and feedback from >>> Stefaan. >>> >>> If nobody objects, I will use the text below to update the text in >>> section 3.4.2 in the ANCP Framework. I will also add the >>> corresponding requirements in section 4.2 (ANCP), 4.7.6 (Access >>> Node) and >>> 4.8.6 (NAS). >>> >>> Regards, >>> Sven >>> >>> --- >>> >>> << Section 3.4.2 >> >>> >>> 3.4.2. Multicast Admission Control >>> >>> << first part of the section remains unchanged. The text from the >>> second bullet onward is updated with below text >> >>> >>> o Another approach is the reverse: it consists of the Policy >>> Server >>> querying the AN (either directly, or indirectly via the >>> NAS) so >>> that both unicast and multicast CAC for the access line are >>> performed by the AN. In this case, a subscriber request for a >>> unicast flow (e.g. a Video on Demand session) will trigger a >>> resource request message towards a Policy Server; the latter >>> will >>> then query the AN, that in turn will perform unicast CAC for >>> the >>> access line and respond, indicating whether the unicast >>> request is >>> to be honored or denied. >>> >>> The second scenario can be split in to cases: >>> >>> o In case the Policy Server queries the AN directly, the >>> approach >>> doesn't require the use of ANCP. It is therefore beyond the >>> scope >>> of this document. >>> >>> o In case the Policy Server queries the AN indirectly via the >>> NAS, >>> the interaction can be handled as an ANCP transaction. >>> When the >>> Policy Server queries the NAS, the NAS can use ANCP to query >>> the >>> AN, specifying the Access-Loop-Circuit-ID and the required >>> bandwidth for the requested unicast flow. Upon receiving the >>> query from the NAS, the AN then performs Admission Control and >>> responds to the NAS, indicating if this unicast VoD request >>> can be >>> accepted or denied. >>> >>> 3.4.2.1. When not to perform Admission Control >>> >>> In general, the Access Node and NAS may not be aware of all >>> possible >>> multicast groups that will be streamed in the access network. >>> For >>> instance, it is likely that there will be multicast streams >>> offered >>> across the Internet. For these unknown streams, performing >>> bandwidth >>> admission control may be challenging. >>> >>> To solve this, these requests could be accepted without >>> performing >>> Admission Control. This solution works, provided that the >>> network >>> handles the streams as best effort, so that other streams are not >>> impacted at times of congestion. >>> >>> Disabling Admission Control for unknown stream can be achieved by >>> adding a "catch-all statement" in the Access Node white list or >>> grey >>> list. In case the Access Node queries the NAS, the NAS on his >>> turn >>> will have to accept the request. That way, the unknown streams >>> are >>> not blocked by default. >>> >>> Next, in order to ensure that the streams are handled as best >>> effort, >>> the flow must be marked as such when entering the service >>> provider >>> network. This way, whenever congestion occurs somewhere in the >>> access/aggregation network, this stream will be kicked out >>> before the >>> access provider's own premium content. >>> >>> The above concept is applicable beyond the notion of "Internet >>> streams" or other unknown streams; it can applied to known >>> multicast >>> streams as well. In this case, the Access Node or NAS will >>> accept >>> the stream even when bandwidth may not be sufficient to support >>> the >>> stream. This again requires that the stream is marked as best >>> effort >>> traffic before entering the access/aggregation network. >>> >>> 3.4.2.2. Multicast Admission Control and White Lists >>> >>> As mentioned in section Section 3.4.1, conditional access to >>> popular >>> IPTV channels can be achieved by means of a White and Black list >>> configured on the Access Node. This method allows the Access >>> Node to >>> autonomously decide whether or not access can be granted to a >>> multicast flow. >>> >>> IPTV is an example of a service that will not be offered as best >>> effort, but requires some level of guaranteed Quality of Service. >>> This requires the use of Multicast Admission Control. Hence, if >>> the >>> Access Node wants to autonomously perform the admission process, >>> it >>> must be aware of the bandwidth characteristics of multicast >>> flows. >>> Otherwise, the Access Node would have to query the NAS for >>> Multicast >>> Admission Control; this would defeat the purpose of using a >>> White and >>> Black list. >>> >>> Some network deployments may combine the use of White list, Black >>> list >>> and Grey list. In this case, the AN will be aware of the >>> portion of >>> the bandwidth used on the Access Port for flows matching an >>> entry in >>> the White list. In order to perform Multicast Admission Control >>> for >>> flows matching an entry in the Grey list, the NAS should add the >>> bandwidth characteristics of the flow in the Admission Response >>> message. In this model, the AN would query the NAS for >>> conditional >>> access, and would then locally perform Multicast Conditional >>> Access, >>> using the bandwidth information retrieved from the NAS. >>> >>> << Section 4.2: add following requirements >> >>> >>> o The ANCP MUST support providing an Access Node with bandwidth >>> information associated with multicast flows that are part of a >>> White list. >>> >>> o The ANCP SHOULD allow the NAS to indicate the bandwidth >>> information, associated with the requested multicast flows, >>> in the >>> admission decision sent to the AN. >>> >>> o In case a unicast and multicast stream share resources on an >>> Access Port, the ANCP MUST allow the NAS to query the AN to >>> request an admission decision for a unicast flow to be sent >>> over that Port. >>> >>> << Section 4.7.6: add following requirements >> >>> >>> o The AN must be able to perform Admission Control for multicast >>> streams, using the bandwith information of the requested >>> multicast >>> flow. The information may be provisioned by a management >>> system >>> or by the NAS (using a Control Reqest message or an Admission >>> Response message). >>> >>> o Upon receiving a query from the NAS to request an admission >>> decision for a unicast flow to be sent over a particular >>> Access >>> Port, the AN must support using ANCP to reply to the NAS, >>> indicating whether the request is to be honored or denied. >>> >>> >>> << Section 4.8.6: add following requirements >> >>> >>> o The NAS should support using ANCP to configure multicast >>> admission control information to Access Ports on an Access >>> Node. >>> >>> o Upon receiving a query from the AN for a request to replicate >>> a >>> multicast flow to a particular Access Port, the NAS should >>> support >>> using ANCP to reply to the AN indicating the bandwidth >>> information, >>> associated with the requested multicast flow. >>> >>> o Upon receiving a request from a Policy Server for a unicast >>> flow >>> to be sent over a particular Access Port, the NAS must support >>> using ANCP to query the AN to receive a response indicating >>> whether the request is to be honored or denied. >>> >>> --- >>> >>> Sven Ooghe >>> Alcatel-Lucent >>> CTO Office, Access Division >>> Copernicuslaan 50, 2018 Antwerp, Belgium >>> tel.: +32 3 240 42 26 >>> fax: +32 3 240 40 73 >>> >>> This message (including any attachments) contains confidential >>> information intended for a specific individual and purpose, and is >>> protected by law. If you are not the intended recipient, you should >>> delete this message. Any disclosure, copying, or distribution of >>> this >>> message, or the taking of any action based on it, is strictly >>> prohibited >>> without the prior consent of its author. >>> >>> >>> >>> _______________________________________________ >>> ANCP mailing list >>> ANCP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ancp >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www1.ietf.org/mailman/listinfo/ancp > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp --Boundary_(ID_d4griPtYVOnSpC9upYPWWw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Sven, Francois et al,
Sorry not replying earlier. I was chairing ITU-T Q.5/11 meeting in Seoul last week, and am in Shenzhen now, and will spend my Spring Festival holidays in Korea next week without internet access.
 
I would let Roberta to reply further if needed:)
 
We support Sven's texts. Minor refinement might be needed.
 
Thanks for all your good comments:) Please see my comments below in line demarked with [Tina: ...].
 
B. R.
Tina
----- Original Message -----
From: OOGHE Sven
Sent: Thursday, January 31, 2008 8:19 PM
Subject: RE: [ANCP] ANCP Multicast Admission Control

Hi Francois,

For clarification: The text concerning PS-->AN and PS-->NAS-->AN
interactions is based on the proposal sent by Tina and Roberta in
http://www1.ietf.org/mail-archive/web/ancp/current/msg00446.html. At
that point in time, there was no feedback on the proposal yet.

I see you have concerns with the approach. Tina or Roberta, can you
share your point of view?

Regards,
Sven

-----Original Message-----
From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com]
Sent: donderdag 31 januari 2008 12:37
To: DE CNODDER Stefaan
Cc: Francois Le Faucheur IMAP; OOGHE Sven; ancp@ietf.org
Subject: Re: [ANCP] ANCP Multicast Admission Control

Hi Stefaan,

On 30 Jan 2008, at 18:32, Stefaan DE CNODDER wrote:

>
> Francois,
>
>> In addition, it is not clear to me how useful these additional models

>> are. It also raises a number of questions. For example, if the Policy

>> Server wants to query the AN, should it do so via the NAS instead of

>> directly to AN?
[Tina: Some slight preference is to via the NAS, as there are many ANs.
Via NAS may reduce the connections. From the point of view of AN, it may
like single interface to NAS rather than one interface to NAS and the other
interface to PS.]
 
>
> Both are possible, is there any preferred way according to you?
>
>  Also, to be able to perform complete Video CAC, the  AN
>> would have to maintain user policy information (eg what is the  
>> fraction of line bandwidth that can be used for Video for that  
>> subscriber at that point in time considering the current DSL train 
>> rate). Is this in line with current ANCP model?
[Tina: Raising this scenario is to implement unciast CAC through ANCP.
AN only maintains bandwidth information, no user policy information.]
 
>> how is user info made available to AN?
[Tina: In AN or PS, manually configure multicast and unicast user bandwidth.]
 
>> What impact does all this have on ANCP?
[Tina: No impact. It expand the ANCP scenario, ANCP can support
 unicast/multicast CAC.]

>> While we can start discussing those questions and the usefulness of 
>> such a model, IMHO this should not delay progress of current ANCP 
>> documents.
>> So in short, I do _not_ support the additional text below relating to

>> the introduction of the new additional model (PS-->NAS-->AN) and 
>> corresponding additional ANCP requirements.
>
> does this mean that you prefer PS-->AN?

No.
I am not expressing any preference for PS-->AN over PS-->NAS-->AN There
seemed to be a lot of additional text proposed below relating to
PS-->NAS-->AN as this involves ANCP more heavily. And I am simply
stating that I do not support adding such text.

The current framework defines PS-->AN and PS-->NAS-->AN as out of scope
for now ("It is therefore beyond the scope of this document.") and I
recommend we do not change scope at this stage if we want to have a
first version of the ANCP protocol in the targeted timeframe. 
Those can always be easily added to the scope/protocol once there is
stronger consensus/understanding or their applicability in the group and
when the WG has completed the first base protocol spec.

Francois


> To be honest, for me both options are valid.  Is there any specific
> reason why you would not like to have the request going to the NAS?
>
> regards,
> Stefaan
>
>
>> Cheers
>> Francois
>> On 28 Jan 2008, at 14:18, OOGHE Sven wrote:
>>> Hi,
>>>
>>> Based on the discussion on the list, I have prepared the following 
>>> text proposal concerning multicast conditional access. I tried to
>>> cover the different scenarios that were identified on the list. This

>>> includes  the proposal from Tina and Roberta, and feedback from
>>> Stefaan.
>>>
>>> If nobody objects, I will use the text below to update the text in
>>> section 3.4.2 in the ANCP Framework. I will also add the
>>> corresponding requirements in section 4.2 (ANCP), 4.7.6 (Access
>>> Node) and
>>> 4.8.6  (NAS).
>>>
>>> Regards,
>>> Sven
>>>
>>> ---
>>>
>>> << Section 3.4.2 >>
>>>
>>> 3.4.2.  Multicast Admission Control
>>>
>>> << first part of the section remains unchanged. The text from the 
>>> second bullet onward is updated with below text >>
>>>
>>>   o  Another approach is the reverse: it consists of the Policy
>>> Server
>>>       querying the AN (either directly, or indirectly via the
>>> NAS) so
>>>       that both unicast and multicast CAC for the access line are
>>>       performed by the AN.  In this case, a subscriber request for a
>>>       unicast flow (e.g. a Video on Demand session) will trigger a
>>>       resource request message towards a Policy Server; the latter 
>>> will
>>>       then query the AN, that in turn will perform unicast CAC for
>>> the
>>>       access line and respond, indicating whether the unicast  
>>> request is
>>>       to be honored or denied.
>>>
>>>    The second scenario can be split in to cases:
>>>
>>>    o  In case the Policy Server queries the AN directly, the
>>> approach
>>>       doesn't require the use of ANCP.  It is therefore beyond the 
>>> scope
>>>       of this document.
>>>
>>>    o  In case the Policy Server queries the AN indirectly via the
>>> NAS,
>>>       the interaction can be handled as an ANCP transaction.  
>>> When the
>>>       Policy Server queries the NAS, the NAS can use ANCP to query
>>> the
>>>       AN, specifying the Access-Loop-Circuit-ID and the required
>>>       bandwidth for the requested unicast flow.  Upon receiving the
>>>       query from the NAS, the AN then performs Admission Control and
>>>       responds to the NAS, indicating if this unicast VoD request 
>>> can be
>>>       accepted or denied.
>>>
>>> 3.4.2.1.  When not to perform Admission Control
>>>
>>>    In general, the Access Node and NAS may not be aware of all  
>>> possible
>>>    multicast groups that will be streamed in the access network.  
>>> For
>>>    instance, it is likely that there will be multicast streams
>>> offered
>>>    across the Internet.  For these unknown streams, performing  
>>> bandwidth
>>>    admission control may be challenging.
>>>
>>>    To solve this, these requests could be accepted without
>>> performing
>>>    Admission Control.  This solution works, provided that the
>>> network
>>>    handles the streams as best effort, so that other streams are not
>>>    impacted at times of congestion.
>>>
>>>    Disabling Admission Control for unknown stream can be achieved by
>>>    adding a "catch-all statement" in the Access Node white list or 
>>> grey
>>>    list.  In case the Access Node queries the NAS, the NAS on his
>>> turn
>>>    will have to accept the request.  That way, the unknown streams
>>> are
>>>    not blocked by default.
>>>
>>>    Next, in order to ensure that the streams are handled as best  
>>> effort,
>>>    the flow must be marked as such when entering the service
>>> provider
>>>    network.  This way, whenever congestion occurs somewhere in the
>>>    access/aggregation network, this stream will be kicked out  
>>> before the
>>>    access provider's own premium content.
>>>
>>>    The above concept is applicable beyond the notion of "Internet
>>>    streams" or other unknown streams; it can applied to known  
>>> multicast
>>>    streams as well.  In this case, the Access Node or NAS will
>>> accept
>>>    the stream even when bandwidth may not be sufficient to support
>>> the
>>>    stream.  This again requires that the stream is marked as best 
>>> effort
>>>    traffic before entering the access/aggregation network.
>>>
>>> 3.4.2.2.  Multicast Admission Control and White Lists
>>>
>>>    As mentioned in section Section 3.4.1, conditional access to  
>>> popular
>>>    IPTV channels can be achieved by means of a White and Black list
>>>    configured on the Access Node.  This method allows the Access  
>>> Node to
>>>    autonomously decide whether or not access can be granted to a
>>>    multicast flow.
>>>
>>>    IPTV is an example of a service that will not be offered as best
>>>    effort, but requires some level of guaranteed Quality of Service.
>>>    This requires the use of Multicast Admission Control.  Hence, if

>>> the
>>>    Access Node wants to autonomously perform the admission process,
>>> it
>>>    must be aware of the bandwidth characteristics of multicast
>>> flows.
>>>    Otherwise, the Access Node would have to query the NAS for  
>>> Multicast
>>>    Admission Control; this would defeat the purpose of using a  
>>> White and
>>>    Black list.
>>>
>>>    Some network deployments may combine the use of White list, Black

>>> list
>>>    and Grey list.  In this case, the AN will be aware of the  
>>> portion of
>>>    the bandwidth used on the Access Port for flows matching an  
>>> entry in
>>>    the White list.  In order to perform Multicast Admission Control

>>> for
>>>    flows matching an entry in the Grey list, the NAS should add the
>>>    bandwidth characteristics of the flow in the Admission Response
>>>    message.  In this model, the AN would query the NAS for
>>> conditional
>>>    access, and would then locally perform Multicast Conditional  
>>> Access,
>>>    using the bandwidth information retrieved from the NAS.
>>>
>>> << Section 4.2: add following requirements >>
>>>
>>>    o  The ANCP MUST support providing an Access Node with bandwidth
>>>       information associated with multicast flows that are part of a
>>>       White list.
>>>
>>>    o  The ANCP SHOULD allow the NAS to indicate the bandwidth
>>>       information, associated with the requested multicast flows, 
>>> in the
>>>       admission decision sent to the AN.
>>>
>>>    o  In case a unicast and multicast stream share resources on an
>>>       Access Port, the ANCP MUST allow the NAS to query the AN to
>>>       request an admission decision for a unicast flow to be sent
>>>       over that Port.
>>>
>>> << Section 4.7.6: add following requirements >>
>>>
>>>    o  The AN must be able to perform Admission Control for multicast
>>>       streams, using the bandwith information of the requested  
>>> multicast
>>>       flow.  The information may be provisioned by a management
>>> system
>>>       or by the NAS (using a Control Reqest message or an Admission
>>>       Response message).
>>>
>>>    o  Upon receiving a query from the NAS to request an admission
>>>       decision for a unicast flow to be sent over a particular
>>> Access
>>>       Port, the AN must support using ANCP to reply to the NAS,
>>>       indicating whether the request is to be honored or denied.
>>>
>>>
>>> << Section 4.8.6: add following requirements >>
>>>
>>>    o  The NAS should support using ANCP to configure multicast
>>>       admission control information to Access Ports on an Access
>>> Node.
>>>
>>>    o  Upon receiving a query from the AN for a request to replicate
>>> a
>>>       multicast flow to a particular Access Port, the NAS should  
>>> support
>>>       using ANCP to reply to the AN indicating the bandwidth
>>> information,
>>>       associated with the requested multicast flow.
>>>
>>>    o  Upon receiving a request from a Policy Server for a unicast
>>> flow
>>>       to be sent over a particular Access Port, the NAS must support
>>>       using ANCP to query the AN to receive a response indicating
>>>       whether the request is to be honored or denied.
>>>
>>> ---
>>>
>>> Sven Ooghe
>>> Alcatel-Lucent
>>> CTO Office, Access Division
>>> Copernicuslaan 50, 2018 Antwerp, Belgium
>>> tel.: +32 3 240 42 26
>>> fax: +32 3 240 40 73
>>>
>>> This message (including any attachments) contains confidential
>>> information intended for a specific individual and purpose, and is
>>> protected by law.  If you are not the intended recipient, you should

>>> delete this message.  Any disclosure, copying, or distribution of
>>> this
>>> message, or the taking of any action based on it, is strictly  
>>> prohibited
>>> without the prior consent of its author.
>>>
>>>
>>>
>>> _______________________________________________
>>> ANCP mailing list
>>> ANCP@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ancp
>> _______________________________________________
>> ANCP mailing list
>> ANCP@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ancp
>
>
> _______________________________________________
> ANCP mailing list
> ANCP@ietf.org
> https://www1.ietf.org/mailman/listinfo/ancp
--Boundary_(ID_d4griPtYVOnSpC9upYPWWw)-- --===============1986659688== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp --===============1986659688==-- From ancp-bounces@ietf.org Mon Feb 4 08:46:35 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F963A6FC1; Mon, 4 Feb 2008 08:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r96tq8eNSBe8; Mon, 4 Feb 2008 08:46:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E3D73A6FC2; Mon, 4 Feb 2008 08:46:33 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 114303A6F02 for ; Mon, 4 Feb 2008 08:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J66vscmXXXDC for ; Mon, 4 Feb 2008 08:46:30 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 67FB13A6F65 for ; Mon, 4 Feb 2008 08:45:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,303,1199660400"; d="scan'208,217";a="4716529" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 04 Feb 2008 17:46:39 +0100 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 m14Gkdwe029431 for ; Mon, 4 Feb 2008 17:46:39 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m14GkYJb025727 for ; Mon, 4 Feb 2008 16:46:39 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 17:46:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Feb 2008 17:46:29 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP behaviour for rate change Thread-Index: AchnTX2va3eQ8GiCRbGeaMGHm166Ww== From: "Wojciech Dec (wdec)" To: X-OriginalArrivalTime: 04 Feb 2008 16:46:34.0340 (UTC) FILETIME=[80573240:01C8674D] Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [ANCP] ANCP behaviour for rate change X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 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="===============2113831882==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============2113831882== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8674D.8030BF79" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8674D.8030BF79 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I have a question about the expected behaviour of ANCP following line-rate changes. At the same time I would request that this behaviour be detailed in the appropriate drafts (Section 5.4.2 of protocol draft would appear to be a reasonable place for this). Let's say that a line rate initially comes up at rate X. This is communicated in a Port-Up message. Then, the line rate re-trains to rate Y. Is ANCP's expected behaviour to: a) Send a new Port-up with Rate Y b) Send a Port-down followed by a Port-Up with rate Y. Behaviour a) would IMO be highly preferable and described in the text. Comments? Regards, Woj. ------_=_NextPart_001_01C8674D.8030BF79 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ANCP behaviour for rate change

Hi = All,

I have a question = about the expected behaviour of ANCP following line-rate changes. At the = same time I would request that this behaviour be detailed in the = appropriate drafts (Section 5.4.2 of protocol draft would appear to be a = reasonable place for this).

Let's say that a = line rate initially comes up at rate X. This is communicated in a = Port-Up message.
Then, the line = rate re-trains to rate Y. Is ANCP's expected behaviour to:
a) Send a new = Port-up with Rate Y
b) Send a = Port-down followed by a Port-Up with rate Y.

Behaviour a) would = IMO be highly preferable and described in the text.

Comments?

Regards,
Woj.

------_=_NextPart_001_01C8674D.8030BF79-- --===============2113831882== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp --===============2113831882==-- From ancp-bounces@ietf.org Mon Feb 4 09:09:45 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079A83A6FAA; Mon, 4 Feb 2008 09:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=1, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov+fqlemI9bm; Mon, 4 Feb 2008 09:09:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07E513A6EB0; Mon, 4 Feb 2008 09:09:44 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E26673A6EB0 for ; Mon, 4 Feb 2008 09:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTX9LHzI0RT1 for ; Mon, 4 Feb 2008 09:09:41 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 28BA13A6DFD for ; Mon, 4 Feb 2008 09:09:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,303,1199660400"; d="scan'208,217";a="4719510" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 04 Feb 2008 18:11:15 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m14HBE04012875; Mon, 4 Feb 2008 18:11:14 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m14HB0Jf006091; Mon, 4 Feb 2008 17:11:14 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 18:11:10 +0100 Received: from [144.254.53.198] ([144.254.53.198]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 18:11:10 +0100 In-Reply-To: <018601c86653$dfb5a000$564c460a@china.huawei.com> References: <7168964CAC5C144685272595141B6DBA1EC3F1@FRVELSMBS22.ad2.ad.alcatel.com> <47A0B490.2040605@alcatel-lucent.be> <7168964CAC5C144685272595141B6DBA233C10@FRVELSMBS22.ad2.ad.alcatel.com> <018601c86653$dfb5a000$564c460a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v753) X-Priority: 3 Message-Id: From: Francois Le Faucheur IMAP Date: Mon, 4 Feb 2008 18:11:03 +0100 To: Tina TSOU X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 04 Feb 2008 17:11:10.0371 (UTC) FILETIME=[F01FA730:01C86750] Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: OOGHE Sven , ancp@ietf.org Subject: Re: [ANCP] ANCP Multicast Admission Control X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 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="===============1834846283==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org --===============1834846283== Content-Type: multipart/alternative; boundary=Apple-Mail-15-499564693 --Apple-Mail-15-499564693 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Tina, On 3 Feb 2008, at 11:59, Tina TSOU wrote: > > > >> how is user info made available to AN? > [Tina: In AN or PS, manually configure multicast and unicast user > bandwidth.] > > >> What impact does all this have on ANCP? > [Tina: No impact. It expand the ANCP scenario, ANCP can support > unicast/multicast CAC.] If this has no impact on ANCP, then the current text should be just fine. The current text: * (i) describes that there is another model for CAC ie PS-->AN or PS-->NAS-->AN, * (ii) clarifies that it does not require ANCP extensions (and thus is outside scope for ANCP). Your description above seems to be in line with the text as it is today (which is fine by me too). I think some have different ideas about how ANCP could play a role in the PS-->AN and PS-->NAS-->AN and therefore involve some specific ANCP extensions. I recommend we do not try rush those in the first deliverables of ANCP WG. Once these additional models are understood and agreed, they can be added to the next version of ANCP deliverables. Cheers Francois --Apple-Mail-15-499564693 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Tina,

On 3 Feb 2008, at 11:59, Tina TSOU = wrote:
=A0
>> = how is user info made available to AN?
[Tina: In AN or PS, manually configure = multicast and unicast user bandwidth.]
=A0
>> What impact = does all this have on ANCP?
[Tina: No = impact. It expand the ANCP scenario, ANCP can = support
=A0unicast/multicast = CAC.]

If = this has no impact on ANCP, then the current text should be just fine. = The current text:
* (i)=A0describes that there is = another model for CAC ie PS-->AN or = PS-->NAS-->AN,=A0
* (ii) clarifies that it does not = require ANCP extensions (and thus is outside=A0scope for = ANCP).=A0
Your description above seems to be in line with the = text as it is today (which is fine by me too).

I think some have = different ideas about how ANCP could play a role in the PS-->AN and = PS-->NAS-->AN and therefore involve some specific ANCP = extensions.
I recommend we do not try rush those in the first = deliverables of ANCP WG. Once these additional models are understood and = agreed, they can be added to the next version of ANCP = deliverables.

Cheers

Francois



= --Apple-Mail-15-499564693-- --===============1834846283== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp --===============1834846283==-- From ancp-bounces@ietf.org Wed Feb 6 07:53:03 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA5C3A6EE8; Wed, 6 Feb 2008 07:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=1, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBvEf0IkTqgD; Wed, 6 Feb 2008 07:52:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0463D3A6E08; Wed, 6 Feb 2008 07:52:56 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222AA3A6EA6 for ; Wed, 6 Feb 2008 07:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgHxJrx6TqHD for ; Wed, 6 Feb 2008 07:52:48 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 82CB83A6F1B for ; Wed, 6 Feb 2008 07:52:47 -0800 (PST) Received: from S4DE8SSAADL.t-systems.com (S4DE8SSAADL.t-systems.com [10.206.178.89]) by tcmail11.telekom.de with ESMTP; Wed, 6 Feb 2008 16:53:51 +0100 Received: from S4DE8SSAAIC.t-systems.com ([10.206.163.5]) by S4DE8SSAADL.t-systems.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Feb 2008 16:36:12 +0100 Received: from S4DE8SSAANB.suedwest.t-com.de ([10.206.163.48]) by S4DE8SSAAIC.t-systems.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Feb 2008 16:36:10 +0100 Received: from S4DE8SSAAMW.suedwest.t-com.de ([10.206.163.52]) by S4DE8SSAANB.suedwest.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Feb 2008 16:35:57 +0100 Received: from S4DE8SSAANC.suedwest.t-com.de ([10.206.163.49]) by S4DE8SSAAMW.suedwest.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Feb 2008 16:25:40 +0100 Received: from S4DE8PSAAGV.mitte.t-com.de ([10.151.180.21]) by S4DE8SSAANC.suedwest.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Feb 2008 16:25:38 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAAGV.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Feb 2008 16:25:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Feb 2008 16:24:19 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CBEDDAA@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <48214755113BB04F84D958B4F0DE261C051AE3B1@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP behaviour for rate change Thread-Index: AchnTX2va3eQ8GiCRbGeaMGHm166WwAwdtCgADBbKGA= References: <48214755113BB04F84D958B4F0DE261C051AE3B1@xmb-sjc-222.amer.cisco.com> From: "Haag, T" To: , X-OriginalArrivalTime: 06 Feb 2008 15:25:22.0923 (UTC) FILETIME=[7D9373B0:01C868D4] Subject: Re: [ANCP] ANCP behaviour for rate change X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 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="===============2084831805==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============2084831805== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C868D4.2FE4A51D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C868D4.2FE4A51D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Woj, =20 All explanations sound reasonable, but we are talking about an AN implementation and not an ANCP protocol issue. =20 ANCP has to report the port status. That's the basic task of ANCP per definition.=20 =20 Let me distinguish between two scenarios: =20 Scenario 1 Regular operation: =20 If line is up but line rate changes happen then option a) "Send a new Port-up with Rate Y" is preferable. =20 =20 =20 Scenario 2 Fault condition: =20 If a port is toggling the AN has to integrate a certain period of time the port status and to decide then if the port is up or down. So the port has to send a port down message following the periodically change between port up/down status. The period is determined by timer value to be set by configuration.=20 =20 So this happens in option b) "Send a Port-down followed by a Port-Up with rate Y". =20 =20 Result: =20 Sending a port down message followed by a port up message is necessary during resynchronisation in case of fault condition. IMO this is an implementation issue of an AN. ANCP has to be prepared to support both scenarios! =20 Regards Thomas =20 ________________________________ Von: Philippe Champagne (pchamp) [mailto:pchamp@cisco.com]=20 Gesendet: Dienstag, 5. Februar 2008 16:58 An: Wojciech Dec (wdec); ancp@ietf.org Betreff: Re: [ANCP] ANCP behaviour for rate change =20 Hi Woj =20 I agree with (a) otherwise it implies twice as many messages There is that part in section 5.4.2: =20 The message SHOULD be generated when a line first comes UP, or any of the=20 attributes of the line change e.g. the line re-trains to a different=20 rate or one or more of the configured line attributes are=20 administratively modified. =20 So, it sounds like it is covering that. Is that what you were referring to but to be worded more specifically? Or perhaps you missed this text or I'm the one off track? Regards Phil =20 =20 =20 =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Monday, February 04, 2008 11:46 AM To: ancp@ietf.org Subject: [ANCP] ANCP behaviour for rate change Hi All,=20 I have a question about the expected behaviour of ANCP following line-rate changes. At the same time I would request that this behaviour be detailed in the appropriate drafts (Section 5.4.2 of protocol draft would appear to be a reasonable place for this). Let's say that a line rate initially comes up at rate X. This is communicated in a Port-Up message.=20 Then, the line rate re-trains to rate Y. Is ANCP's expected behaviour to:=20 a) Send a new Port-up with Rate Y=20 b) Send a Port-down followed by a Port-Up with rate Y.=20 Behaviour a) would IMO be highly preferable and described in the text.=20 Comments?=20 Regards,=20 Woj.=20 ------_=_NextPart_001_01C868D4.2FE4A51D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable ANCP behaviour for rate change

Hi = Woj,

 

All explanations = sound reasonable, but we are talking about an AN implementation and not an = ANCP protocol issue.

 =

ANCP has to = report the port status. That’s the basic task of ANCP per definition. =

 =

Let me = distinguish between two scenarios:

 =

= Scenario 1 Regular operation:

 

If line is up = but line rate changes happen then option a) “Send = a new Port-up with Rate Y” is preferable.

 =

 =

 =

= Scenario 2 Fault condition:

 =

If a port is = toggling the AN has to integrate a certain period of time the port status and to = decide then if the port is up or down.

So the port has = to send a port down message following the periodically change between port up/down = status. The period is determined by timer value to be set by configuration. =

 =

So this happens = in option b) “Send a Port-down followed by a Port-Up with = rate Y”.

 =

 =

= Result:

 =

Sending a port = down message followed by a port up message is necessary during = resynchronisation in case of fault condition. IMO this is an implementation issue of an AN. = ANCP has to be prepared to support both scenarios!

 =

Regards

Thomas

 =

Von: = Philippe Champagne (pchamp) [mailto:pchamp@cisco.com]
Gesendet: Dienstag, 5. = Februar 2008 16:58
An: Wojciech Dec (wdec); ancp@ietf.org
Betreff: Re: [ANCP] ANCP = behaviour for rate change

 

Hi Woj

 

I agree with (a) otherwise it = implies twice as many messages

There is that part in section 5.4.2:

 

    The message SHOULD be = generated when a line first comes UP, or any of the
     attributes of the line change e.g. the line = re-trains to a different
     rate or one or more of the configured line = attributes are
     administratively = modified.

 

So, it sounds like it is covering = that. Is that what you were referring to but to be worded more specifically? Or perhaps you missed this text or I'm the one = off track?

Regards

=

Phil

 

 

 

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec)
Sent: Monday, February = 04, 2008 11:46 AM
To: ancp@ietf.org
Subject: [ANCP] ANCP = behaviour for rate change

Hi All,

I have a question about the expected behaviour of ANCP following line-rate changes. At the same time I would request that this behaviour = be detailed in the appropriate drafts (Section 5.4.2 of protocol draft = would appear to be a reasonable place for this).

Let's say that a line rate initially comes up at rate X. This is communicated in a Port-Up message.
Then, the line rate re-trains to rate Y. Is ANCP's expected = behaviour to:
a) Send a new Port-up with Rate Y
b) Send a Port-down followed by a Port-Up with rate = Y.

Behaviour a) would IMO be highly preferable and described in the = text.

Comments?

Regards,
Woj.

------_=_NextPart_001_01C868D4.2FE4A51D-- --===============2084831805== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp --===============2084831805==-- From ancp-bounces@ietf.org Wed Feb 6 11:50:10 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 541993A6F3B; Wed, 6 Feb 2008 11:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Lko0cWCHBfe; Wed, 6 Feb 2008 11:50:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466CE3A6E69; Wed, 6 Feb 2008 11:50:09 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401163A6E69 for ; Wed, 6 Feb 2008 11:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTflc8BUaH63 for ; Wed, 6 Feb 2008 11:50:04 -0800 (PST) Received: from maill.telecomitalia.it (maill.telecomitalia.it [217.169.121.52]) by core3.amsl.com (Postfix) with ESMTP id D18FD3A6D2E for ; Wed, 6 Feb 2008 11:50:03 -0800 (PST) Received: from ptpxch009rm001.idc.cww.telecomitalia.it ([156.54.205.171]) by maill.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 20:51:34 +0100 Received: from PTPEVS103RM001.idc.cww.telecomitalia.it ([156.54.208.23]) by ptpxch009rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 20:51:34 +0100 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Feb 2008 20:51:33 +0100 Message-ID: <6FCF06DE599E7C4690E588F22B45AE1C0241FE13@PTPEVS103RM001.idc.cww.telecomitalia.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Multicast Admission Control thread-index: AchnUPOHwvCTEFQ8Qd2CjiUszg3T0gBp7881 References: <7168964CAC5C144685272595141B6DBA1EC3F1@FRVELSMBS22.ad2.ad.alcatel.com> <47A0B490.2040605@alcatel-lucent.be> <7168964CAC5C144685272595141B6DBA233C10@FRVELSMBS22.ad2.ad.alcatel.com> <018601c86653$dfb5a000$564c460a@china.huawei.com> From: "Maglione Roberta" To: X-OriginalArrivalTime: 06 Feb 2008 19:51:34.0345 (UTC) FILETIME=[AD490B90:01C868F9] Cc: Ullio Mario , OOGHE Sven Subject: Re: [ANCP] ANCP Multicast Admission Control X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi Sven, Francois and All, sorry for my late reply. As Tina and I wrote in the first email current ANCP framework draft in second bullet of section 3.4.2 already mentions the scenario where a Policy Server queries the AN directly or indirectly. As Tina said in some cases it could be more convenient for the PS to go through the NAS instead of querying the AN directly in order to reduce scalability issues because the NAS could be seen as an aggregation point for multiple Access nodes. As far as the impacts on ANCP I agree that in order to support the indirect scenario, PS->NAS->AN, with the interaction NAS->AN handled via ANCP some extensions are required to the ANCP protocol. I understand the concerns raised on mailing list about adding new requirement not fully agreed by the WG at this stage, in particular given the time constrains for the current ANCP protocol completion according to the scheduled milestones. If the working group does not reach the consensus on this point IMHO one possibility could be to have an high level description of the depicted scenario in order to keep track of this use case and then to postpone the design of the protocol details required to fulfill this scenario in next phase of ANCP protocol. The intention is to make sure that the current protocol design does not prevent adding the additional scenario in next phase. What do you think? Thanks and best regards, Roberta -----Original Message----- From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] Sent: Mon 2/4/2008 6:11 PM To: Tina TSOU Cc: Francois Le Faucheur IMAP; Maglione Roberta; OOGHE Sven; ancp@ietf.org Subject: Re: [ANCP] ANCP Multicast Admission Control Hi Tina, On 3 Feb 2008, at 11:59, Tina TSOU wrote: > > > >> how is user info made available to AN? > [Tina: In AN or PS, manually configure multicast and unicast user > bandwidth.] > > >> What impact does all this have on ANCP? > [Tina: No impact. It expand the ANCP scenario, ANCP can support > unicast/multicast CAC.] If this has no impact on ANCP, then the current text should be just fine. The current text: * (i) describes that there is another model for CAC ie PS-->AN or PS-->NAS-->AN, * (ii) clarifies that it does not require ANCP extensions (and thus is outside scope for ANCP). Your description above seems to be in line with the text as it is today (which is fine by me too). I think some have different ideas about how ANCP could play a role in the PS-->AN and PS-->NAS-->AN and therefore involve some specific ANCP extensions. I recommend we do not try rush those in the first deliverables of ANCP WG. Once these additional models are understood and agreed, they can be added to the next version of ANCP deliverables. Cheers Francois -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Feb 13 10:20:12 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98CA28C79F; Wed, 13 Feb 2008 10:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.919 X-Spam-Level: X-Spam-Status: No, score=-2.919 tagged_above=-999 required=5 tests=[AWL=-2.482, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 269Oa-3i0PUI; Wed, 13 Feb 2008 10:20:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA9233A6A9A; Wed, 13 Feb 2008 10:20:11 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C90328C6B3 for ; Wed, 13 Feb 2008 10:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huT-vi-QmtRZ for ; Wed, 13 Feb 2008 10:20:07 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DB18E3A6D20 for ; Wed, 13 Feb 2008 10:20:06 -0800 (PST) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Feb 2008 19:21:29 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1DILTWg024212; Wed, 13 Feb 2008 19:21:29 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1DILTen001851; Wed, 13 Feb 2008 18:21:29 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Feb 2008 19:21:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Feb 2008 19:21:41 +0100 Message-ID: In-Reply-To: <6FCF06DE599E7C4690E588F22B45AE1C0241FE13@PTPEVS103RM001.idc.cww.telecomitalia.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Multicast Admission Control Thread-Index: AchnUPOHwvCTEFQ8Qd2CjiUszg3T0gBp7881AVzhHhA= X-Priority: 1 Priority: Urgent Importance: high References: <7168964CAC5C144685272595141B6DBA1EC3F1@FRVELSMBS22.ad2.ad.alcatel.com><47A0B490.2040605@alcatel-lucent.be><7168964CAC5C144685272595141B6DBA233C10@FRVELSMBS22.ad2.ad.alcatel.com><018601c86653$dfb5a000$564c460a@china.huawei.com> <6FCF06DE599E7C4690E588F22B45AE1C0241FE13@PTPEVS103RM001.idc.cww.telecomitalia.it> From: "Wojciech Dec (wdec)" To: X-OriginalArrivalTime: 13 Feb 2008 18:21:28.0826 (UTC) FILETIME=[403C8DA0:01C86E6D] Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [ANCP] ANCP Multicast Admission Control X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Folks, given the latest batch of discussions we'd like to set a course for the WG and design team regarding work on ANCP multicast control extensions, if not also other extensions. The latest proposals regarding multicast control put forward at least two additional CAC deployment models to the one that is primarily addressed by the current framework. The current framework text represents a WG consensus arrived at after much discussion, and it is our reasoned opinion that in attempting to adopt the proposals at this stage (the framework document was supposedly ready for last-call) we will run a serious risk of a prolonged discussions on the various models leading to potentially derailing the consensus arrived at so far. All of this will have a direct knock-on effect in delaying significantly the chartered completion of the ANCP protocol spec, which happens to already be behind schedule. At the same time it would be unfortunate to stop such discussions if there continues to be interest in progressing the proposals to a stage where they can be included in the framework. As such, we would like to set the following direction which in our opinion strikes a fair balance between the current work and future work on ANCP: - We would like to ask the WG to arrive at a high level text proposal for the framework draft regarding protocol extensions in general, amongst others to potentially address alternative CAC deployment models at a later stage. It is too early to include detailed requirements as proposed by some on these at this stage, however discussion can proceed on the alias. - The design team and WG will be asked to pursue at this stage towards a protocol specification without explicitly realizing the mechanisms for the alternative CAC models, but looking at extensibility in general. Given a suitable message and TLV extension scheme there appears to be no problem in having the protocol support new CAC models, or other ANCP usage schemes in the future. - When the frame-work draft reaches its Last-call I-D milestone, we'll have a WG decision on re-chartering or adding new mile-stones protocol specification/extension phases. We trust that with the above direction in place we'll be able to obtain rapid progress, without closing the door on extensions. Regards, Woj & Matthew. _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Feb 14 00:48:30 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B3D63A7068; Thu, 14 Feb 2008 00:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.129 X-Spam-Level: X-Spam-Status: No, score=-0.129 tagged_above=-999 required=5 tests=[AWL=-2.119, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgK+dyyQEm4f; Thu, 14 Feb 2008 00:48:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E5B53A7063; Thu, 14 Feb 2008 00:48:29 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 315A13A7062 for ; Thu, 14 Feb 2008 00:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zq4c76qf52Pu for ; Thu, 14 Feb 2008 00:48:27 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 8A3523A7061 for ; Thu, 14 Feb 2008 00:48:24 -0800 (PST) Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m1E8bnpI023176 for ; Thu, 14 Feb 2008 09:38:30 +0100 Received: from [172.31.131.165] ([172.31.131.165]) by FRVELSBHS07.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Thu, 14 Feb 2008 09:49:09 +0100 Message-ID: <47B40081.9010505@alcatel-lucent.be> Date: Thu, 14 Feb 2008 09:49:05 +0100 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 X-OriginalArrivalTime: 14 Feb 2008 08:49:09.0277 (UTC) FILETIME=[76AEF4D0:01C86EE6] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: [ANCP] ANCP MIB X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi, In revising the ANCP MIB for access nodes, there will be mainly minor updates but maybe two update deserves somewhat more attention: 1) The textual conventions defining the TCs GsmpSubVersion and AncpSessionCapabilities (previously named AncpAnSessionCapabilities), will be taken out the ANCP MIB module for access nodes, and will be put in a separate MIB module (also defined in the same document). 2) The ANCP MIB modules (we have 2 now) will not be put directly under mib-2, but under ancpMIB. ANCP will have its own node ancpMIB and all ANCP MIB mdoules can be put under mib-2. These changes will be done (except if someone has another opinion) to make the ANCP MIBs more general, to better support other ANCP related MIB modules in the future. Thanks, Stefaan _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Feb 14 00:57:16 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B95B93A6F80; Thu, 14 Feb 2008 00:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.928 X-Spam-Level: X-Spam-Status: No, score=-0.928 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WtXlj7zW9YE; Thu, 14 Feb 2008 00:57:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F254F28C848; Thu, 14 Feb 2008 00:57:15 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3483B3A6B08 for ; Thu, 14 Feb 2008 00:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5wA9Sr8rJJH for ; Thu, 14 Feb 2008 00:57:13 -0800 (PST) Received: from nj300815-nj-outbound.avaya.com (unknown [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id C24313A682B for ; Thu, 14 Feb 2008 00:57:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,351,1199682000"; d="scan'208";a="99442328" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 14 Feb 2008 03:58:33 -0500 X-IronPort-AV: E=Sophos;i="4.25,351,1199682000"; d="scan'208";a="155175488" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 14 Feb 2008 03:58:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Feb 2008 09:58:15 +0100 Message-ID: In-Reply-To: <47B40081.9010505@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP MIB Thread-Index: Achu5pYrj170nSLIRhiVE3fI9geEeQAALp+A References: <47B40081.9010505@alcatel-lucent.be> From: "Romascanu, Dan (Dan)" To: "Stefaan DE CNODDER" , Subject: Re: [ANCP] ANCP MIB X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi Stefaan, For the two ANCP MIB modules, do you plan to request the allocation one root OID under mib-2 or two? RFC 4181 believes two (and more down the road if needed) is better. Dan > -----Original Message----- > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On > Behalf Of Stefaan DE CNODDER > Sent: Thursday, February 14, 2008 10:49 AM > To: ancp@ietf.org > Subject: [ANCP] ANCP MIB > > > Hi, > > In revising the ANCP MIB for access nodes, there will be > mainly minor updates but maybe two update deserves somewhat > more attention: > > 1) The textual conventions defining the TCs GsmpSubVersion > and AncpSessionCapabilities (previously named > AncpAnSessionCapabilities), will be taken out the ANCP MIB > module for access nodes, and will be put in a separate MIB > module (also defined in the same document). > > 2) The ANCP MIB modules (we have 2 now) will not be put > directly under mib-2, but under ancpMIB. ANCP will have its > own node ancpMIB and all ANCP MIB mdoules can be put under mib-2. > > These changes will be done (except if someone has another > opinion) to make the ANCP MIBs more general, to better > support other ANCP related MIB modules in the future. > > Thanks, > Stefaan > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > http://www.ietf.org/mailman/listinfo/ancp > _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Feb 14 01:20:21 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2583A702C; Thu, 14 Feb 2008 01:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.27 X-Spam-Level: X-Spam-Status: No, score=-0.27 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQGezjwqw0ul; Thu, 14 Feb 2008 01:20:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B884A3A6D36; Thu, 14 Feb 2008 01:20:20 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 154103A6B08 for ; Thu, 14 Feb 2008 01:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9bqOj8u4u6E for ; Thu, 14 Feb 2008 01:20:19 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 0548C3A6EEF for ; Thu, 14 Feb 2008 01:20:18 -0800 (PST) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m1E99rIs018469; Thu, 14 Feb 2008 10:10:19 +0100 Received: from [172.31.131.165] ([172.31.131.165]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Thu, 14 Feb 2008 10:21:15 +0100 Message-ID: <47B4080A.5060208@alcatel-lucent.be> Date: Thu, 14 Feb 2008 10:21:14 +0100 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: "Romascanu, Dan (Dan)" References: <47B40081.9010505@alcatel-lucent.be> In-Reply-To: X-OriginalArrivalTime: 14 Feb 2008 09:21:15.0586 (UTC) FILETIME=[F2DA6220:01C86EEA] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: ancp@ietf.org Subject: Re: [ANCP] ANCP MIB X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi Dan, Actually, the intend was to have only 1 OID under mib-2 to have something like: ancpMIB ::= { mib-2 xxx } ancpTcMIB ::= { ancpMIB 1 } ancpAnMIB ::= { ancpMIB 2 } and a new future ANCP MIB module would use { ancpMIB 3 }. But indeed, when looking to RFC 4181, it looks that this way of working is not recommended. Should it then be as follows? ancpTcMIB ::= { mib-2 xxx } ancpAnMIB ::= { mib-2 yyy } and a new future ANCP MIB module will be { mib-2 zzz }. If the intend of RFC 4181 is the latter (so no ancpMIB), then we will use that. Thanks, Stefaan Romascanu, Dan (Dan) wrote: > Hi Stefaan, > > For the two ANCP MIB modules, do you plan to request the allocation one > root OID under mib-2 or two? RFC 4181 believes two (and more down the > road if needed) is better. > > Dan > > > > > > >>-----Original Message----- >>From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On >>Behalf Of Stefaan DE CNODDER >>Sent: Thursday, February 14, 2008 10:49 AM >>To: ancp@ietf.org >>Subject: [ANCP] ANCP MIB >> >> >>Hi, >> >>In revising the ANCP MIB for access nodes, there will be >>mainly minor updates but maybe two update deserves somewhat >>more attention: >> >>1) The textual conventions defining the TCs GsmpSubVersion >>and AncpSessionCapabilities (previously named >>AncpAnSessionCapabilities), will be taken out the ANCP MIB >>module for access nodes, and will be put in a separate MIB >>module (also defined in the same document). >> >>2) The ANCP MIB modules (we have 2 now) will not be put >>directly under mib-2, but under ancpMIB. ANCP will have its >>own node ancpMIB and all ANCP MIB mdoules can be put under mib-2. >> >>These changes will be done (except if someone has another >>opinion) to make the ANCP MIBs more general, to better >>support other ANCP related MIB modules in the future. >> >>Thanks, >>Stefaan >> >>_______________________________________________ >>ANCP mailing list >>ANCP@ietf.org >>http://www.ietf.org/mailman/listinfo/ancp > > _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Feb 14 01:30:52 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B759E28CD94; Thu, 14 Feb 2008 01:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LvfGwkqaaCQ; Thu, 14 Feb 2008 01:30:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CEA128CD89; Thu, 14 Feb 2008 01:30:51 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA3928CD5B for ; Thu, 14 Feb 2008 01:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bXdJZiIgPUz for ; Thu, 14 Feb 2008 01:30:49 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (unknown [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id B2EA228C66E for ; Thu, 14 Feb 2008 01:30:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,351,1199682000"; d="scan'208";a="92476891" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Feb 2008 04:32:08 -0500 X-IronPort-AV: E=Sophos;i="4.25,351,1199682000"; d="scan'208";a="155199456" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 14 Feb 2008 04:32:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Feb 2008 10:31:38 +0100 Message-ID: In-Reply-To: <47B4080A.5060208@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP MIB Thread-Index: Achu6wM6NGfNTz4YStiFIQXUQxvGlgAABjPQ References: <47B40081.9010505@alcatel-lucent.be> <47B4080A.5060208@alcatel-lucent.be> From: "Romascanu, Dan (Dan)" To: "Stefaan DE CNODDER" Cc: ancp@ietf.org Subject: Re: [ANCP] ANCP MIB X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org I would actually not recommend this, because this will make the ANCP WG the eternal registry authority responsible for OID allocation, instead of leaving this task to IANA, which has a well defined process with an exact timing about when the OID needs to be allocated. There are a few other good reasons for this which I can explain if you wish. I suggest that you change this now, otherwise you will get almost surely comments in MIB Doctor reviews. See the example in RFC4181 of the power Ethernet MIB, which although is a MIB is not under an Ethernet tree administered by the WG, but directly under mib-2. Regards, Dan > -----Original Message----- > From: Stefaan DE CNODDER > [mailto:stefaan.de_cnodder@alcatel-lucent.be] > Sent: Thursday, February 14, 2008 11:21 AM > To: Romascanu, Dan (Dan) > Cc: ancp@ietf.org > Subject: Re: [ANCP] ANCP MIB > > > Hi Dan, > > Actually, the intend was to have only 1 OID under mib-2 to > have something like: > > ancpMIB ::= { mib-2 xxx } > ancpTcMIB ::= { ancpMIB 1 } > ancpAnMIB ::= { ancpMIB 2 } > > and a new future ANCP MIB module would use { ancpMIB 3 }. > > But indeed, when looking to RFC 4181, it looks that this way > of working is not recommended. Should it then be as follows? > > ancpTcMIB ::= { mib-2 xxx } > ancpAnMIB ::= { mib-2 yyy } > > and a new future ANCP MIB module will be { mib-2 zzz }. > > If the intend of RFC 4181 is the latter (so no ancpMIB), then > we will use that. > > Thanks, > Stefaan > > > > Romascanu, Dan (Dan) wrote: > > > Hi Stefaan, > > > > For the two ANCP MIB modules, do you plan to request the allocation > > one root OID under mib-2 or two? RFC 4181 believes two (and > more down > > the road if needed) is better. > > > > Dan > > > > > > > > > > > > > >>-----Original Message----- > >>From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] > On Behalf > >>Of Stefaan DE CNODDER > >>Sent: Thursday, February 14, 2008 10:49 AM > >>To: ancp@ietf.org > >>Subject: [ANCP] ANCP MIB > >> > >> > >>Hi, > >> > >>In revising the ANCP MIB for access nodes, there will be > mainly minor > >>updates but maybe two update deserves somewhat more attention: > >> > >>1) The textual conventions defining the TCs GsmpSubVersion and > >>AncpSessionCapabilities (previously named > AncpAnSessionCapabilities), > >>will be taken out the ANCP MIB module for access nodes, and will be > >>put in a separate MIB module (also defined in the same document). > >> > >>2) The ANCP MIB modules (we have 2 now) will not be put > directly under > >>mib-2, but under ancpMIB. ANCP will have its own node > ancpMIB and all > >>ANCP MIB mdoules can be put under mib-2. > >> > >>These changes will be done (except if someone has another > >>opinion) to make the ANCP MIBs more general, to better > support other > >>ANCP related MIB modules in the future. > >> > >>Thanks, > >>Stefaan > >> > >>_______________________________________________ > >>ANCP mailing list > >>ANCP@ietf.org > >>http://www.ietf.org/mailman/listinfo/ancp > > > > > > This email was protected during delivery to Avaya with TLS encryption > > _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Feb 15 00:51:20 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4D863A6A42; Fri, 15 Feb 2008 00:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sTCmESpw6Vt; Fri, 15 Feb 2008 00:51:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C36F3A6966; Fri, 15 Feb 2008 00:51:20 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 550EC3A6966 for ; Fri, 15 Feb 2008 00:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERMoC3Vz8ZU6 for ; Fri, 15 Feb 2008 00:51:17 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 053493A68AC for ; Fri, 15 Feb 2008 00:51:16 -0800 (PST) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP for ancp@ietf.org; Fri, 15 Feb 2008 09:52:36 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Feb 2008 09:52:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Feb 2008 09:52:35 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C81F76F@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: missing items in the ancp-mib draft Thread-Index: Achvr/OBsEZD2YTzRgWc2jm+MszNPw== From: "Freudenberger, Markus" To: X-OriginalArrivalTime: 15 Feb 2008 08:52:35.0949 (UTC) FILETIME=[1C4859D0:01C86FB0] Cc: "Haag, T" , "Busser, M" Subject: [ANCP] missing items in the ancp-mib draft X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi all, looking into the actual ancp-mib draft, I am misssing the following: 1) the possibilty to configure the IP address on the AN for the control cha= nnel as it is already defined for the peer NAS. This implies adding additio= nal entries into the ancpAnCurrentSessionTable for reading the control chan= nel ip address of the NAS. 2) the possibility to configure the allocation of control channel(s) to a p= hysical interface with VPI/VCI resp. C-/S-VAN-ID values and Qos/CoS setting= . = Both is required to allow the EMS the setup of the control channel with SNM= P and this is described in Section 6 of the ancp framework document anyway = (See below). = ----------------------- snip from draft-ietf-ancp-framework-04.txt --------= --------------- 6. Management Related Requirements o It must be possible to configure the following parameters on the Access Node and the NAS: * Parameters related to the Control Channel transport method: these include the VPI/VCI and transport characteristics (e.g. VBR-rt or CBR) for ATM networks or the C-VLAN ID and S-VLAN ID and p-bit marking for Ethernet networks; * Parameters related to the Control Channel itself: these include the IP address of the IP interface on the Access Node and the NAS ----------------------- snip from draft-ietf-ancp-framework-04.txt --------= --------------- Any comments? Regards Markus Freudenberger = T-Systems Enterprise Services GmbH Systems Integration Telco Project & Design Line of Business Networks & Processes Technology Consultant Deutsche-Telekom-Allee 7, D-64295 Darmstadt +49 6151 937-3679 (Phone) = +49 6151 937-19875 (Fax) = +49 521 5224 5816 (PC-Fax) = E-Mail: mailto:markus.freudenberger@t-systems.com = Internet: http://t-systems.com >T-Systems Enterprise Services GmbH >Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) >Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, Albe= rt Henn, Olaf Heyden*, Katrin Horstmann, Wilfried Peters*, = >Dr. Herbert Schaaff*, Zvezdana Seeger* >Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 >Sitz der Gesellschaft: Frankfurt am Main >WEEE-Reg.-Nr. DE87523644 >*Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG > Notice: This transmittal and/or attachments may be privileged or confidenti= al. If you are not the intended recipient, you are hereby notified that you= have received this transmittal in error; any review, dissemination, or cop= ying is strictly prohibited. If you received this transmittal in error, ple= ase notify us immediately by reply and immediately delete this message and = all its attachments. Thank you. T-Systems - Business flexibility _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Feb 15 01:43:31 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA6A928CFF7; Fri, 15 Feb 2008 01:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.252 X-Spam-Level: X-Spam-Status: No, score=-0.252 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADyoeSHLqjbV; Fri, 15 Feb 2008 01:43:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF75F28CFB4; Fri, 15 Feb 2008 01:43:30 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D5AA28CF73 for ; Fri, 15 Feb 2008 01:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mak359zk9Dk9 for ; Fri, 15 Feb 2008 01:43:28 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 0789528CEB8 for ; Fri, 15 Feb 2008 01:43:27 -0800 (PST) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m1F9XLCP001517; Fri, 15 Feb 2008 10:33:21 +0100 Received: from [172.31.131.165] ([172.31.131.165]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Fri, 15 Feb 2008 10:44:46 +0100 Message-ID: <47B55F0E.7040205@alcatel-lucent.be> Date: Fri, 15 Feb 2008 10:44:46 +0100 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: "Freudenberger, Markus" References: <1B6169C658325341A3B8066E23919E1C81F76F@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1B6169C658325341A3B8066E23919E1C81F76F@S4DE8PSAANK.mitte.t-com.de> X-OriginalArrivalTime: 15 Feb 2008 09:44:46.0809 (UTC) FILETIME=[666BAC90:01C86FB7] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "Haag, T" , "Busser, M" , ancp@ietf.org Subject: Re: [ANCP] missing items in the ancp-mib draft X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi Markus, The parameters related to control channel has been intentionally not = been included in the ANCP MIB because these attributes are to be = configured in other MIBs. For instance, if the VLAN on which ANCP is = running needs p-bit 5, then that is to be configured in the = corresponding ethernet MIB where VLANs are configured. The same for = PVCs: I guess there are ATM MIBs where the attributes of all the PVCs = can be configured. Then you also need the selection of the VLAN or PVC to be used for ANCP. = Actually, ANCP are IP packets originated from an IP address in the AN, = and transmitted like any other IP packet, i.e., the AN performs an IP = lookup in its routing table. So if the correct routing cannot be = achieved because the IP address of the directly attached interface of = the "ANCP VLAN" is not used as NAS address, then an appriopriate route = has to be configured such that these packets are going to the VLAN on = which they should be. However, also this "routing information" (in = whatever form) is to be configured in other MIBs than the ANCP MIB. Look it like this in case of ethernet: if the AN generates an ANCP = message to the NAS, then the ANCP message is put in an ethernet frame, = this ethernet frame needs a MAC destination address. To get the MAC = destination address, the AN has to send an ARP to an IP address. This = IP address is the next-hop IP address, which it gets from the routing = information. It can be a next-hop of a route, or in case the NAS IP = address is directly attached, the IP packet matches the direct route. So I have the feeling that this "routing information" for ANCP can exist = in multiple forms: (1) a route with next-hop, or directly attached (2) a VLAN (so no next-hop and then the NAS IP must be directly attached = for sending an ARP). - ... So I have the feeling that this just do not belong to an ANCP MIB. For = sure option (1) should not be in the ANCP MIB, (2) could be added but = since a generic solution anyhow requires (1), I do not see the need to = add something in the ANCP MIB. Extra filters in the ANCP MIB could be added like for instance that ANCP = messages may only be sent or received on particular VLANs, but that is = just an extra ACL, and each implementation can add as much security as = needed and this should maybe not be in a standard ANCP MIB. Do you agree with this? Thanks for the review, all comments are very welcome. regards, Stefaan Freudenberger, Markus wrote: > Hi all, > = > looking into the actual ancp-mib draft, I am misssing the following: > = > 1) the possibilty to configure the IP address on the AN for the control c= hannel as it is already defined for the peer NAS. This implies adding addit= ional entries into the ancpAnCurrentSessionTable for reading the control ch= annel ip address of the NAS. > = > 2) the possibility to configure the allocation of control channel(s) to a= physical interface with VPI/VCI resp. C-/S-VAN-ID values and Qos/CoS setti= ng. = > = > Both is required to allow the EMS the setup of the control channel with S= NMP and this is described in Section 6 of the ancp framework document anywa= y (See below). = > = > ----------------------- snip from draft-ietf-ancp-framework-04.txt ------= ----------------- > 6. Management Related Requirements > = > o It must be possible to configure the following parameters on the > Access Node and the NAS: > = > * Parameters related to the Control Channel transport method: > these include the VPI/VCI and transport characteristics (e.g. > VBR-rt or CBR) for ATM networks or the C-VLAN ID and S-VLAN ID > and p-bit marking for Ethernet networks; > = > * Parameters related to the Control Channel itself: these include > the IP address of the IP interface on the Access Node and the > NAS > ----------------------- snip from draft-ietf-ancp-framework-04.txt ------= ----------------- > = > Any comments? > = > Regards > Markus Freudenberger = > = > T-Systems Enterprise Services GmbH > Systems Integration > Telco Project & Design > Line of Business Networks & Processes > Technology Consultant > Deutsche-Telekom-Allee 7, D-64295 Darmstadt > +49 6151 937-3679 (Phone) = > +49 6151 937-19875 (Fax) = > +49 521 5224 5816 (PC-Fax) = > E-Mail: mailto:markus.freudenberger@t-systems.com = > Internet: http://t-systems.com > = > = >>T-Systems Enterprise Services GmbH >>Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) >>Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, Alb= ert Henn, Olaf Heyden*, Katrin Horstmann, Wilfried Peters*, = >>Dr. Herbert Schaaff*, Zvezdana Seeger* >>Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 >>Sitz der Gesellschaft: Frankfurt am Main >>WEEE-Reg.-Nr. DE87523644 >>*Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG >> > = > Notice: This transmittal and/or attachments may be privileged or confiden= tial. If you are not the intended recipient, you are hereby notified that y= ou have received this transmittal in error; any review, dissemination, or c= opying is strictly prohibited. If you received this transmittal in error, p= lease notify us immediately by reply and immediately delete this message an= d all its attachments. Thank you. > T-Systems - Business flexibility > = > = > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > http://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Feb 15 06:16:40 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A7F028D1E0; Fri, 15 Feb 2008 06:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGZYwPGxjqPh; Fri, 15 Feb 2008 06:16:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5696C28D1F9; Fri, 15 Feb 2008 06:16:34 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 472A828D162 for ; Fri, 15 Feb 2008 06:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzxQ7LzTYFsf for ; Fri, 15 Feb 2008 06:16:31 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 004FB28D209 for ; Fri, 15 Feb 2008 06:15:12 -0800 (PST) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Fri, 15 Feb 2008 15:16:33 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Feb 2008 15:16:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Feb 2008 15:16:32 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C81F775@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <47B55F0E.7040205@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] missing items in the ancp-mib draft Thread-Index: Achvt3MzoTltir36TnW1Xqv9A5YZmQAIs9eg References: <1B6169C658325341A3B8066E23919E1C81F76F@S4DE8PSAANK.mitte.t-com.de> <47B55F0E.7040205@alcatel-lucent.be> From: "Freudenberger, Markus" To: X-OriginalArrivalTime: 15 Feb 2008 14:16:32.0746 (UTC) FILETIME=[5D8434A0:01C86FDD] Cc: "Haag, T" , "Busser, M" , ancp@ietf.org Subject: Re: [ANCP] missing items in the ancp-mib draft X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi Stefaan, I am sure that other MIBs already provide attributes to meet these requirem= ents but then they must be linked anyhow to the ANCP MIB to provide a compl= ete specification. So, the minimum is, to state this in the document, e. g. that allocating AN= CP channels to Ethernet VLANs/ATM-VC's is configured with "xyz-MIB". The better approach, I think, is to identify the needed atttributes from al= ready published standard MIBs and link them to the ANCP MIB. According 1): I didn't completely got your point. Do you mean that configuring an IP addr= ess in the AN is not necessary because it is allocated by other means (ARP?= )? If I am right than we should add an attribute into the SessionTable to read= it with SNMP. Regards Markus -----Urspr=FCngliche Nachricht----- Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] = Gesendet: Freitag, 15. Februar 2008 10:45 An: Freudenberger, Markus Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org Betreff: Re: [ANCP] missing items in the ancp-mib draft Hi Markus, The parameters related to control channel has been intentionally not been i= ncluded in the ANCP MIB because these attributes are to be configured in ot= her MIBs. For instance, if the VLAN on which ANCP is running needs p-bit 5= , then that is to be configured in the corresponding ethernet MIB where VLA= Ns are configured. The same for PVCs: I guess there are ATM MIBs where the attributes of all the PVCs can b= e configured. Then you also need the selection of the VLAN or PVC to be used for ANCP. = Actually, ANCP are IP packets originated from an IP address in the AN, an= d transmitted like any other IP packet, i.e., the AN performs an IP lookup = in its routing table. So if the correct routing cannot be achieved because= the IP address of the directly attached interface of the "ANCP VLAN" is no= t used as NAS address, then an appriopriate route has to be configured such= that these packets are going to the VLAN on which they should be. However= , also this "routing information" (in whatever form) is to be configured in= other MIBs than the ANCP MIB. Look it like this in case of ethernet: if the AN generates an ANCP message = to the NAS, then the ANCP message is put in an ethernet frame, this etherne= t frame needs a MAC destination address. To get the MAC destination addres= s, the AN has to send an ARP to an IP address. This IP address is the next= -hop IP address, which it gets from the routing information. It can be a n= ext-hop of a route, or in case the NAS IP address is directly attached, the= IP packet matches the direct route. So I have the feeling that this "routing information" for ANCP can exist in= multiple forms: (1) a route with next-hop, or directly attached (2) a VLAN (so no next-hop and then the NAS IP must be directly attached fo= r sending an ARP). - ... So I have the feeling that this just do not belong to an ANCP MIB. For sur= e option (1) should not be in the ANCP MIB, (2) could be added but since a = generic solution anyhow requires (1), I do not see the need to add somethin= g in the ANCP MIB. Extra filters in the ANCP MIB could be added like for instance that ANCP me= ssages may only be sent or received on particular VLANs, but that is just a= n extra ACL, and each implementation can add as much security as needed and= this should maybe not be in a standard ANCP MIB. Do you agree with this? Thanks for the review, all comments are very welcome. regards, Stefaan Freudenberger, Markus wrote: > Hi all, > = > looking into the actual ancp-mib draft, I am misssing the following: > = > 1) the possibilty to configure the IP address on the AN for the control c= hannel as it is already defined for the peer NAS. This implies adding addit= ional entries into the ancpAnCurrentSessionTable for reading the control ch= annel ip address of the NAS. > = > 2) the possibility to configure the allocation of control channel(s) to a= physical interface with VPI/VCI resp. C-/S-VAN-ID values and Qos/CoS setti= ng. = > = > Both is required to allow the EMS the setup of the control channel with S= NMP and this is described in Section 6 of the ancp framework document anywa= y (See below). = > = > ----------------------- snip from draft-ietf-ancp-framework-04.txt = > ----------------------- 6. Management Related Requirements > = > o It must be possible to configure the following parameters on the > Access Node and the NAS: > = > * Parameters related to the Control Channel transport method: > these include the VPI/VCI and transport characteristics (e.g. > VBR-rt or CBR) for ATM networks or the C-VLAN ID and S-VLAN ID > and p-bit marking for Ethernet networks; > = > * Parameters related to the Control Channel itself: these include > the IP address of the IP interface on the Access Node and the > NAS > ----------------------- snip from draft-ietf-ancp-framework-04.txt = > ----------------------- > = > Any comments? > = > Regards > Markus Freudenberger > = > T-Systems Enterprise Services GmbH > Systems Integration > Telco Project & Design > Line of Business Networks & Processes > Technology Consultant > Deutsche-Telekom-Allee 7, D-64295 Darmstadt > +49 6151 937-3679 (Phone) > +49 6151 937-19875 (Fax) > +49 521 5224 5816 (PC-Fax) > E-Mail: mailto:markus.freudenberger@t-systems.com > Internet: http://t-systems.com > = > = >>T-Systems Enterprise Services GmbH >>Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: = >>Reinhard Clemens (Vorsitzender)*, Helmut Binder, Albert Henn, Olaf = >>Heyden*, Katrin Horstmann, Wilfried Peters*, Dr. Herbert Schaaff*, = >>Zvezdana Seeger* >>Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der = >>Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 = >>*Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG >> > = > Notice: This transmittal and/or attachments may be privileged or confiden= tial. If you are not the intended recipient, you are hereby notified that y= ou have received this transmittal in error; any review, dissemination, or c= opying is strictly prohibited. If you received this transmittal in error, p= lease notify us immediately by reply and immediately delete this message an= d all its attachments. Thank you. > T-Systems - Business flexibility > = > = > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > http://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Sun Feb 17 14:28:57 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E205E3A6B72; Sun, 17 Feb 2008 14:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.665 X-Spam-Level: X-Spam-Status: No, score=-0.665 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0GwsZZmkZqS; Sun, 17 Feb 2008 14:28:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B89383A6A73; Sun, 17 Feb 2008 14:28:55 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6FFA3A6880 for ; Sun, 17 Feb 2008 14:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVIH0VU6TdgR for ; Sun, 17 Feb 2008 14:28:53 -0800 (PST) Received: from eci-iron1.ecitele.com (eci-iron1.ecitele.com [147.234.242.117]) by core3.amsl.com (Postfix) with ESMTP id 949663A67F8 for ; Sun, 17 Feb 2008 14:28:52 -0800 (PST) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 17 Feb 2008 14:23:40 +0200 Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 17 Feb 2008 13:56:23 +0200 Received: from ILPTMAIL01.ecitele.com (147.234.245.210) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server id 8.1.240.5; Sun, 17 Feb 2008 13:56:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 17 Feb 2008 13:56:15 +0200 Message-ID: <83153A1EB675AF4F82E134FA27F95F6702F354FA@ilptex01.ecitele.com> In-Reply-To: <47B55F0E.7040205@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] missing items in the ancp-mib draft Thread-Index: Achvt2zW2zBsQZ2hTpm2bEK8NY4hKgBnyl7Q References: <1B6169C658325341A3B8066E23919E1C81F76F@S4DE8PSAANK.mitte.t-com.de> <47B55F0E.7040205@alcatel-lucent.be> From: Moti Morgenstern To: "Stefaan DE CNODDER" , "Freudenberger, Markus" X-OriginalArrivalTime: 17 Feb 2008 11:56:23.0172 (UTC) FILETIME=[1DD88C40:01C8715C] Cc: "Haag, T" , "Busser, M" , ancp@ietf.org Subject: Re: [ANCP] missing items in the ancp-mib draft X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi, I think what Markus wrote is pretty correct. There should be, for example, = a MIB for associating ANCP session with "ANCP VLAN". So, if that MIB is alr= eady available, in already existing RFCs, then the ANCP MIB should include = a section describing that as part of the "Relationship to Other MIB Modules= ", as done with the interfaces MIB. That will allow software engineers (eve= n if not members in our honorable ANCP WG) to see the whole picture. Howeve= r, if such a MIB is not available, then obviously the ANCP MIB should descr= ibe what is the gap and define the MIB for filling it. = More specifically (and please correct me if I'm wrong): - I do not recall a MIB for ATM PVCs that assumes single VC with multiplexe= d services. However, in this case I think that we do not need such a MIB be= cause the ANCP control channel should actually be associated with bridge po= rt (and that bridge port has a MIB that provides the information on the und= erlying L2). The question is how does the EMS associate the ANCP control ch= annel with a specific bridge port? - Stefaan says that "ANCP are IP packets originated from an IP address in t= he AN" and that's correct. But how does the EMS configure that address? How= does the EMS associate it with one of possibly multiple sessions? I'll be glad to hear more opinions on those issues. Regards, Moti -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Ste= faan DE CNODDER Sent: Friday, February 15, 2008 11:45 AM To: Freudenberger, Markus Cc: Haag, T; Busser,M; ancp@ietf.org Subject: Re: [ANCP] missing items in the ancp-mib draft Hi Markus, The parameters related to control channel has been intentionally not = been included in the ANCP MIB because these attributes are to be = configured in other MIBs. For instance, if the VLAN on which ANCP is = running needs p-bit 5, then that is to be configured in the = corresponding ethernet MIB where VLANs are configured. The same for = PVCs: I guess there are ATM MIBs where the attributes of all the PVCs = can be configured. Then you also need the selection of the VLAN or PVC to be used for ANCP. = Actually, ANCP are IP packets originated from an IP address in the AN, = and transmitted like any other IP packet, i.e., the AN performs an IP = lookup in its routing table. So if the correct routing cannot be = achieved because the IP address of the directly attached interface of = the "ANCP VLAN" is not used as NAS address, then an appriopriate route = has to be configured such that these packets are going to the VLAN on = which they should be. However, also this "routing information" (in = whatever form) is to be configured in other MIBs than the ANCP MIB. Look it like this in case of ethernet: if the AN generates an ANCP = message to the NAS, then the ANCP message is put in an ethernet frame, = this ethernet frame needs a MAC destination address. To get the MAC = destination address, the AN has to send an ARP to an IP address. This = IP address is the next-hop IP address, which it gets from the routing = information. It can be a next-hop of a route, or in case the NAS IP = address is directly attached, the IP packet matches the direct route. So I have the feeling that this "routing information" for ANCP can exist = in multiple forms: (1) a route with next-hop, or directly attached (2) a VLAN (so no next-hop and then the NAS IP must be directly attached = for sending an ARP). - ... So I have the feeling that this just do not belong to an ANCP MIB. For = sure option (1) should not be in the ANCP MIB, (2) could be added but = since a generic solution anyhow requires (1), I do not see the need to = add something in the ANCP MIB. Extra filters in the ANCP MIB could be added like for instance that ANCP = messages may only be sent or received on particular VLANs, but that is = just an extra ACL, and each implementation can add as much security as = needed and this should maybe not be in a standard ANCP MIB. Do you agree with this? Thanks for the review, all comments are very welcome. regards, Stefaan Freudenberger, Markus wrote: > Hi all, > = > looking into the actual ancp-mib draft, I am misssing the following: > = > 1) the possibilty to configure the IP address on the AN for the control c= hannel as it is already defined for the peer NAS. This implies adding addit= ional entries into the ancpAnCurrentSessionTable for reading the control ch= annel ip address of the NAS. > = > 2) the possibility to configure the allocation of control channel(s) to a= physical interface with VPI/VCI resp. C-/S-VAN-ID values and Qos/CoS setti= ng. = > = > Both is required to allow the EMS the setup of the control channel with S= NMP and this is described in Section 6 of the ancp framework document anywa= y (See below). = > = > ----------------------- snip from draft-ietf-ancp-framework-04.txt ------= ----------------- > 6. Management Related Requirements > = > o It must be possible to configure the following parameters on the > Access Node and the NAS: > = > * Parameters related to the Control Channel transport method: > these include the VPI/VCI and transport characteristics (e.g. > VBR-rt or CBR) for ATM networks or the C-VLAN ID and S-VLAN ID > and p-bit marking for Ethernet networks; > = > * Parameters related to the Control Channel itself: these include > the IP address of the IP interface on the Access Node and the > NAS > ----------------------- snip from draft-ietf-ancp-framework-04.txt ------= ----------------- > = > Any comments? > = > Regards > Markus Freudenberger = > = > T-Systems Enterprise Services GmbH > Systems Integration > Telco Project & Design > Line of Business Networks & Processes > Technology Consultant > Deutsche-Telekom-Allee 7, D-64295 Darmstadt > +49 6151 937-3679 (Phone) = > +49 6151 937-19875 (Fax) = > +49 521 5224 5816 (PC-Fax) = > E-Mail: mailto:markus.freudenberger@t-systems.com = > Internet: http://t-systems.com > = > = >>T-Systems Enterprise Services GmbH >>Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) >>Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, Alb= ert Henn, Olaf Heyden*, Katrin Horstmann, Wilfried Peters*, = >>Dr. Herbert Schaaff*, Zvezdana Seeger* >>Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 >>Sitz der Gesellschaft: Frankfurt am Main >>WEEE-Reg.-Nr. DE87523644 >>*Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG >> > = > Notice: This transmittal and/or attachments may be privileged or confiden= tial. If you are not the intended recipient, you are hereby notified that y= ou have received this transmittal in error; any review, dissemination, or c= opying is strictly prohibited. If you received this transmittal in error, p= lease notify us immediately by reply and immediately delete this message an= d all its attachments. Thank you. > T-Systems - Business flexibility > = > = > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > http://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Feb 18 00:57:25 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC81D28C218; Mon, 18 Feb 2008 00:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.238 X-Spam-Level: X-Spam-Status: No, score=-0.238 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ONEeVJTeNUY; Mon, 18 Feb 2008 00:57:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8A5328C115; Mon, 18 Feb 2008 00:57:23 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1B5128C209 for ; Mon, 18 Feb 2008 00:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dbi9eYe2prTb for ; Mon, 18 Feb 2008 00:57:21 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 9D5603A6B73 for ; Mon, 18 Feb 2008 00:57:20 -0800 (PST) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m1I8jH1v031166; Mon, 18 Feb 2008 09:45:18 +0100 Received: from [172.31.131.165] ([172.31.131.165]) by FRVELSBHS02.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Mon, 18 Feb 2008 09:57:14 +0100 Message-ID: <47B94869.8030905@alcatel-lucent.be> Date: Mon, 18 Feb 2008 09:57:13 +0100 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: Moti Morgenstern , "Freudenberger, Markus" References: <1B6169C658325341A3B8066E23919E1C81F76F@S4DE8PSAANK.mitte.t-com.de> <47B55F0E.7040205@alcatel-lucent.be> <83153A1EB675AF4F82E134FA27F95F6702F354FA@ilptex01.ecitele.com> In-Reply-To: <83153A1EB675AF4F82E134FA27F95F6702F354FA@ilptex01.ecitele.com> X-OriginalArrivalTime: 18 Feb 2008 08:57:14.0159 (UTC) FILETIME=[415913F0:01C8720C] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "Haag, T" , "Busser, M" , ancp@ietf.org Subject: Re: [ANCP] missing items in the ancp-mib draft X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Moti, Markus, Moti Morgenstern wrote: > Hi, > = > I think what Markus wrote is pretty correct. There should be, for example= , a MIB for associating ANCP session with "ANCP VLAN". So, if that MIB is a= lready available, in already existing RFCs, then the ANCP MIB should includ= e a section describing that as part of the "Relationship to Other MIB Modul= es", as done with the interfaces MIB. That will allow software engineers (e= ven if not members in our honorable ANCP WG) to see the whole picture. Howe= ver, if such a MIB is not available, then obviously the ANCP MIB should des= cribe what is the gap and define the MIB for filling it. = > = > More specifically (and please correct me if I'm wrong): > - I do not recall a MIB for ATM PVCs that assumes single VC with multiple= xed services. However, in this case I think that we do not need such a MIB = because the ANCP control channel should actually be associated with bridge = port (and that bridge port has a MIB that provides the information on the u= nderlying L2). The question is how does the EMS associate the ANCP control = channel with a specific bridge port? An informational text can be added to explain how IP/ANCP packets are to = be routed but there is no formal linking with any other MIB. How the IP = layer is configured is independent from how the protocol is configured. For me it is also fine that ANCP packets are not routed in the AN but = that ANCP is bound to a certain interface (=3DVLAN or PVC) like it is for = instance with OSPF. But then the configured NAS IP address in the AN = must be a directly attached IP address, if the NAS IP address is not = directly attached, then the AN does not know which IP address to ARP = (which it normally gets from the next-hop of the matching route). When ANCP bypasses routing, VLAN-ID or PVC (with some extra attributes = only specific for ANCP packets like for instance p-bits) could be = configured in ancpAnSessionConfigTable. For me both options are fine, but if the second option is selected, the = the framework draft should also mention this limitation (which should = not be a problem if we all agree I suspect). What is your preference? > - Stefaan says that "ANCP are IP packets originated from an IP address in= the AN" and that's correct. But how does the EMS configure that address? H= ow does the EMS associate it with one of possibly multiple sessions? > = It is the IP routing table that associates an ANCP packet (IP packet) to = a certain outgoing interface. The AN IP address is not configured per = session but you can see the selected IP address in = ancpAnCurrentSessionTable. Typically, when a device generates an IP = packet, its IP source address is usually set to the IP address of the = outgoing IP interface. When the AN only has 1 IP address (after all it = is not a router), then it is straitforward. regards, Stefaan > I'll be glad to hear more opinions on those issues. > = > Regards, > Moti > = > = > -----Original Message----- > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of S= tefaan DE CNODDER > Sent: Friday, February 15, 2008 11:45 AM > To: Freudenberger, Markus > Cc: Haag, T; Busser,M; ancp@ietf.org > Subject: Re: [ANCP] missing items in the ancp-mib draft > = > = > Hi Markus, > = > The parameters related to control channel has been intentionally not = > been included in the ANCP MIB because these attributes are to be = > configured in other MIBs. For instance, if the VLAN on which ANCP is = > running needs p-bit 5, then that is to be configured in the = > corresponding ethernet MIB where VLANs are configured. The same for = > PVCs: I guess there are ATM MIBs where the attributes of all the PVCs = > can be configured. > = > Then you also need the selection of the VLAN or PVC to be used for ANCP. = > Actually, ANCP are IP packets originated from an IP address in the AN, = > and transmitted like any other IP packet, i.e., the AN performs an IP = > lookup in its routing table. So if the correct routing cannot be = > achieved because the IP address of the directly attached interface of = > the "ANCP VLAN" is not used as NAS address, then an appriopriate route = > has to be configured such that these packets are going to the VLAN on = > which they should be. However, also this "routing information" (in = > whatever form) is to be configured in other MIBs than the ANCP MIB. > = > Look it like this in case of ethernet: if the AN generates an ANCP = > message to the NAS, then the ANCP message is put in an ethernet frame, = > this ethernet frame needs a MAC destination address. To get the MAC = > destination address, the AN has to send an ARP to an IP address. This = > IP address is the next-hop IP address, which it gets from the routing = > information. It can be a next-hop of a route, or in case the NAS IP = > address is directly attached, the IP packet matches the direct route. > = > So I have the feeling that this "routing information" for ANCP can exist = > in multiple forms: > (1) a route with next-hop, or directly attached > (2) a VLAN (so no next-hop and then the NAS IP must be directly attached = > for sending an ARP). > - ... > = > So I have the feeling that this just do not belong to an ANCP MIB. For = > sure option (1) should not be in the ANCP MIB, (2) could be added but = > since a generic solution anyhow requires (1), I do not see the need to = > add something in the ANCP MIB. > = > Extra filters in the ANCP MIB could be added like for instance that ANCP = > messages may only be sent or received on particular VLANs, but that is = > just an extra ACL, and each implementation can add as much security as = > needed and this should maybe not be in a standard ANCP MIB. > = > Do you agree with this? > = > Thanks for the review, all comments are very welcome. > = > regards, > Stefaan > = > = > Freudenberger, Markus wrote: > = >>Hi all, >> >>looking into the actual ancp-mib draft, I am misssing the following: >> >>1) the possibilty to configure the IP address on the AN for the control c= hannel as it is already defined for the peer NAS. This implies adding addit= ional entries into the ancpAnCurrentSessionTable for reading the control ch= annel ip address of the NAS. >> >>2) the possibility to configure the allocation of control channel(s) to a= physical interface with VPI/VCI resp. C-/S-VAN-ID values and Qos/CoS setti= ng. = >> >>Both is required to allow the EMS the setup of the control channel with S= NMP and this is described in Section 6 of the ancp framework document anywa= y (See below). = >> >>----------------------- snip from draft-ietf-ancp-framework-04.txt ------= ----------------- >>6. Management Related Requirements >> >> o It must be possible to configure the following parameters on the >> Access Node and the NAS: >> >> * Parameters related to the Control Channel transport method: >> these include the VPI/VCI and transport characteristics (e.g. >> VBR-rt or CBR) for ATM networks or the C-VLAN ID and S-VLAN ID >> and p-bit marking for Ethernet networks; >> >> * Parameters related to the Control Channel itself: these include >> the IP address of the IP interface on the Access Node and the >> NAS >>----------------------- snip from draft-ietf-ancp-framework-04.txt ------= ----------------- >> >>Any comments? >> >>Regards >>Markus Freudenberger = >> >>T-Systems Enterprise Services GmbH >>Systems Integration >>Telco Project & Design >>Line of Business Networks & Processes >>Technology Consultant >>Deutsche-Telekom-Allee 7, D-64295 Darmstadt >>+49 6151 937-3679 (Phone) = >>+49 6151 937-19875 (Fax) = >>+49 521 5224 5816 (PC-Fax) = >>E-Mail: mailto:markus.freudenberger@t-systems.com = >>Internet: http://t-systems.com >> >> >> >>>T-Systems Enterprise Services GmbH >>>Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) >>>Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, Al= bert Henn, Olaf Heyden*, Katrin Horstmann, Wilfried Peters*, = >>>Dr. Herbert Schaaff*, Zvezdana Seeger* >>>Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 >>>Sitz der Gesellschaft: Frankfurt am Main >>>WEEE-Reg.-Nr. DE87523644 >>>*Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG >>> >> >>Notice: This transmittal and/or attachments may be privileged or confiden= tial. If you are not the intended recipient, you are hereby notified that y= ou have received this transmittal in error; any review, dissemination, or c= opying is strictly prohibited. If you received this transmittal in error, p= lease notify us immediately by reply and immediately delete this message an= d all its attachments. Thank you. >>T-Systems - Business flexibility >> >> >>_______________________________________________ >>ANCP mailing list >>ANCP@ietf.org >>http://www.ietf.org/mailman/listinfo/ancp > = > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > http://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Feb 18 07:08:54 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB03C28C377; Mon, 18 Feb 2008 07:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=-2.794, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtg8onVJJwxf; Mon, 18 Feb 2008 07:08:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1541F28C31C; Mon, 18 Feb 2008 07:08:54 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 638E328C31C for ; Mon, 18 Feb 2008 07:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rK1zUeWOQuE for ; Mon, 18 Feb 2008 07:08:51 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 65FF428C152 for ; Mon, 18 Feb 2008 07:08:51 -0800 (PST) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Feb 2008 16:08:48 +0100 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 m1IF8mEF008806 for ; Mon, 18 Feb 2008 16:08:48 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1IF8mp6018449 for ; Mon, 18 Feb 2008 15:08:48 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 16:08:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Feb 2008 16:08:44 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Agenda items for IETF71 ANCP WG meeting Thread-Index: AchUUQtbSvlJlJPeRGysqgny0e3nCQd7TxMg References: From: "Wojciech Dec (wdec)" To: X-OriginalArrivalTime: 18 Feb 2008 15:08:48.0413 (UTC) FILETIME=[29C244D0:01C87240] Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [ANCP] Agenda items for IETF71 ANCP WG meeting X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 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="===============1462671576==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1462671576== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87240.29A8AB4C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87240.29A8AB4C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 are there any other calls for slots at the upcoming meeting? =20 So far we have the following: - ANCP Access-node & NAS MIB Update; Stefaan De Cnodder - ANCP Design Team update (tentative) =20 Regards, Woj. ________________________________ From: Wojciech Dec (wdec)=20 Sent: 11 January 2008 14:04 To: ancp@ietf.org Subject: [ANCP] Agenda items for IETF71 ANCP WG meeting=20 =09 =09 We're taking requests for slots in the agenda for our next ANCP WG meeting. Please respond with any tentative requests by February 8. Thanks,=20 Matthew & Woj=20 ------_=_NextPart_001_01C87240.29A8AB4C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda items for IETF71 ANCP WG meeting
Hi All,
 
are there any other calls for slots at the = upcoming=20 meeting?
 
So far we have the = following:
-=20 ANCP Access-node & NAS MIB Update; Stefaan De = Cnodder
-=20 ANCP Design Team update (tentative)
 
Regards,
Woj.

From: Wojciech Dec (wdec) =
Sent: 11=20 January 2008 14:04
To: ancp@ietf.org
Subject: = [ANCP]=20 Agenda items for IETF71 ANCP WG meeting

We're taking requests for slots = in the=20 agenda for our next ANCP WG meeting.  Please respond with any = tentative=20 requests by February 8.

Thanks,
Matthew & Woj

------_=_NextPart_001_01C87240.29A8AB4C-- --===============1462671576== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp --===============1462671576==-- From ancp-bounces@ietf.org Mon Feb 18 09:18:24 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BDEB28C435; Mon, 18 Feb 2008 09:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.324 X-Spam-Level: X-Spam-Status: No, score=-0.324 tagged_above=-999 required=5 tests=[AWL=-0.887, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 504KRfrWTmGv; Mon, 18 Feb 2008 09:18:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFC1828C3C4; Mon, 18 Feb 2008 09:18:22 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 645E228C3A7 for ; Mon, 18 Feb 2008 09:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ni9vTaDzVanc for ; Mon, 18 Feb 2008 09:18:20 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id B587F28C3BB for ; Mon, 18 Feb 2008 09:18:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D203DCB04CB; Mon, 18 Feb 2008 09:18:18 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09743-05; Mon, 18 Feb 2008 09:18:18 -0800 (PST) Received: from rbsjx.ad.redback.com (rbsjxh1.redback.com [155.53.14.105]) by prattle.redback.com (Postfix) with ESMTP id 96929CB04CA; Mon, 18 Feb 2008 09:18:18 -0800 (PST) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh1.ad.redback.com ([155.53.14.105]) with mapi; Mon, 18 Feb 2008 09:18:18 -0800 From: Peter Arberg To: "Wojciech Dec (wdec)" , "ancp@ietf.org" Date: Mon, 18 Feb 2008 09:18:16 -0800 Thread-Topic: Re: [ANCP] Agenda items for IETF71 ANCP WG meeting Thread-Index: AchUUQtbSvlJlJPeRGysqgny0e3nCQd7TxMgAATtZ4A= Message-ID: <48C276B536524E478C659685995F6AA527656DB671@RBSJX.ad.redback.com> In-Reply-To: Accept-Language: da-DK, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: da-DK, en-US Content-Type: multipart/mixed; boundary="_004_48C276B536524E478C659685995F6AA527656DB671RBSJXadredbac_" MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at redback.com Subject: Re: [ANCP] Agenda items for IETF71 ANCP WG meeting X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org --_004_48C276B536524E478C659685995F6AA527656DB671RBSJXadredbac_ Content-Type: multipart/alternative; boundary="_000_48C276B536524E478C659685995F6AA527656DB671RBSJXadredbac_" --_000_48C276B536524E478C659685995F6AA527656DB671RBSJXadredbac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Woj, I just submitted the attached internet draft, and will like to discuss it i= n the next meeting to get it accepted as a WG item. thanks, Peter ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Woj= ciech Dec (wdec) Sent: 18. februar 2008 07:09 To: ancp@ietf.org Subject: Re: [ANCP] Agenda items for IETF71 ANCP WG meeting Hi All, are there any other calls for slots at the upcoming meeting? So far we have the following: - ANCP Access-node & NAS MIB Update; Stefaan De Cnodder - ANCP Design Team update (tentative) Regards, Woj. ________________________________ From: Wojciech Dec (wdec) Sent: 11 January 2008 14:04 To: ancp@ietf.org Subject: [ANCP] Agenda items for IETF71 ANCP WG meeting We're taking requests for slots in the agenda for our next ANCP WG meeting.= Please respond with any tentative requests by February 8. Thanks, Matthew & Woj --_000_48C276B536524E478C659685995F6AA527656DB671RBSJXadredbac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda items for IETF71 ANCP WG meeting
Hi Woj,
 
I just submitted the attached internet draft, and = will like=20 to discuss it in
the next meeting to get it accepted as a WG=20 item.
 
thanks,
Peter

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec=20 (wdec)
Sent: 18. februar 2008 07:09
To:=20 ancp@ietf.org
Subject: Re: [ANCP] Agenda items for IETF71 ANCP = WG=20 meeting

Hi All,
 
are there any other calls for slots at the upc= oming=20 meeting?
 
So far we have the following:
- ANCP Access-node & NAS MIB Update; Stefa= an De=20 Cnodder
- ANCP Design Team update=20 (tentative)
 
Regards,
Woj.

From: Wojciech Dec (wdec)
Se= nt:=20 11 January 2008 14:04
To: ancp@ietf.org
Subject: [A= NCP]=20 Agenda items for IETF71 ANCP WG meeting

We're taking requests for slots = in the=20 agenda for our next ANCP WG meeting.  Please respond with any tent= ative=20 requests by February 8.

Thanks,
Matthew & Woj=20

--_000_48C276B536524E478C659685995F6AA527656DB671RBSJXadredbac_-- --_004_48C276B536524E478C659685995F6AA527656DB671RBSJXadredbac_ Content-Type: text/plain; name="draft-arberg-ancp-vendorspecific-00.txt" Content-Description: draft-arberg-ancp-vendorspecific-00.txt Content-Disposition: attachment; filename="draft-arberg-ancp-vendorspecific-00.txt"; size=0; creation-date="Sun, 17 Feb 2008 23:47:06 GMT"; modification-date="Mon, 18 Feb 2008 17:09:27 GMT" Content-Transfer-Encoding: base64 DQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFBldGVyIEFyYmVyZw0KSW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAg ICAgICAgICAgICAgICAgICAgICBSZWRiYWNrIE5ldHdvcmtzDQpFeHBpcmVzOiBBdWd1c3QgMTcs IDIwMDggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDE3LCAyMDA4DQoN Cg0KDQogICAgICAgICAgICAgICAgVmVuZG9yIFNwZWNpZmljIE1lc3NhZ2UgZm9yIEFOQ1AuDQoN CiAgICAgICAgICAgICAgIGRyYWZ0LWFyYmVyZy1hbmNwLXZlbmRvcnNwZWNpZmljLTAwDQoNCg0K DQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIEJ5IHN1Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1E cmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0aGF0IGFueQ0KICAgYXBwbGljYWJsZSBwYXRl bnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUNCiAgIGhh dmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBvZiB3aGljaCBoZSBvciBzaGUg YmVjb21lcw0KICAgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBT ZWN0aW9uIDYgb2YgQkNQIDc5Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9j dW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURiks IGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdA0KICAgb3RoZXIg Z3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQt DQogICBEcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZh bGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCBy ZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUu ICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNl DQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9n cmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBh Y2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0 Lg0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2Fu IGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLg0KDQog ICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEF1Z3VzdCAxNywgMjAwOC4NCg0K DQpDb3B5cmlnaHQgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoQykgVGhlIElFVEYgVHJ1c3QgKDIw MDgpLg0KDQoNCkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgYWltZWQgYXQgcHJlc2Vu dGluZyBBY2Nlc3MgTm9kZSBDb250cm9sIFByb3RvY29sDQogICAoQU5DUCkgd2l0aCBhIHZlbmRv ciBzcGVjaWZpYyBwcm90b2NvbCBleHRlbnNpb24uIA0KDQoNCg0KDQoNCg0KQXJiZXJnICAgICAg ICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxNywgMjAwOCAgICAgICAgICAgICAgICAgIFtQYWdl IDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIFZlbmRvciBTcGVjaWZpYyBNZXNzYWdlIGZvciBB TkNQICAgICAgIEZlYnJ1YXJ5IDIwMDgNCg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAgMS4gIElu dHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAyDQogICAyLiAgU3BlY2lmaWNhdGlvbiBvZiBSZXF1aXJlbWVudHMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDINCiAgIDMuICBWZW5kb3Igc3BlY2lmaWMgbWVzc2FnZXMg aW4gR1NNUHYzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMg0KICAgNC4gIFZlbmRvciBz cGVjaWZpYyBtZXNzYWdlcyBpbiBBTkNQIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAz DQogICAgIDQuMS4gVmVuZG9yIFNwZWNpZmljIENhcGFiaWxpdHkgTmVnb3RpYXRpb24gIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDMNCiAgICAgNC4yLiBWZW5kb3IgU3BlY2lmaWMgRXh0ZW5zaW9ucyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAgNS4gIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1DQogICA2 LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDUNCiAgIDcuIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNg0KICAgICA3LjEuIE5vcm1hdGl2ZSBSZWZlcmVu Y2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2DQogICBBdXRob3Jz JyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDYNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVudHMg LiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0KDQoNCjEuICBJbnRyb2R1Y3Rpb24NCg0KICAgVGhpcyBk b2N1bWVudCBpcyBhaW1lZCBhdCBwcmVzZW50aW5nIEFOQ1Agd2l0aCBhIHZlbmRvciBzcGVjaWZp Yw0KICAgcHJvdG9jb2wgZXh0ZW5zaW9uLiBHU01QdjMgWzFdIHdoaWNoIGlzIHVzZWQgYXMgZm91 bmRhdGlvbiBmb3IgdGhlDQogICBBTkNQIHByb3RvY29sIFsyXSBhbHJlYWR5IGhhcyB2ZW5kb3Ig c3BlY2lmaWMgZnVuY3Rpb25hbGl0eSBkZWZpbmVkLA0KICAgYnV0IHNpbmNlIEFOQ1AgZGVmaW5l cyBuZXcgY2FwYWJpbGl0eSBuZWdvdGlhdGlvbnMgYW5kIG9ubHkgaW5jbHVkZQ0KICAgZmV3IHNw ZWNpZmljIG1lc3NhZ2VzIGZyb20gR1NNUHYzLCBpdCBpcyBuZWNlc3NhcnkgdG8gZGVmaW5lIGEg bmV3DQogICB2ZW5kb3Igc3BlY2lmaWMgbWVzc2FnZSBoYW5kbGluZyBmb3IgQU5DUC4gDQoNCiAg IFRoaXMgcHJvcG9zYWwgYWltcyBhdCBjb2xsZWN0aW5nIGZlZWRiYWNrIGZyb20gdGhlIEFOQ1Ag Y29tbXVuaXR5IGluIA0KICAgb3JkZXIgdG8gd29yayB0b3dhcmRzIGNvbnNlbnN1cy4gRXZlbnR1 YWxseSwgdGV4dCBkZXJpdmVkIGZyb20gdGhlIA0KICAgbWF0ZXJpYWwgaW4gc2VjdGlvbiA0LiB3 b3VsZCBiZSBpbnRlbmRlZCB0byBiZSBpbmNvcnBvcmF0ZWQgaW4gdGhlDQogICAiQU5DUCBQcm90 b2NvbCBJLUQiIFsyXS4NCg0KDQoyLiAgU3BlY2lmaWNhdGlvbiBvZiBSZXF1aXJlbWVudHMNCg0K ICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIs ICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwg Ik1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRl cnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLg0KDQoNCjMuICBWZW5kb3Igc3BlY2lm aWMgbWVzc2FnZXMgaW4gR1NNUHYzDQoNCiAgIEdTTVB2MyBbMV0gZGVmaW5lcyB2ZW5kb3Igc3Bl Y2lmaWMgcmFuZ2VzIGZvciB2ZW5kb3IgcHJpdmF0ZSANCiAgIGV4dGVuc2lvbnMgdG8gdGhlIEdT TVB2MyBwcm90b2NvbC4gR1NNUHYzIGRlZmluZXMgdmVuZG9yIHNwZWNpZmljDQogICByYW5nZXMg Zm9yIHRoZSBmb2xsb3dpbmcgZnVuY3Rpb25hbGl0aWVzOg0KDQogICAgICAtICBNZXNzYWdlIFR5 cGUgTmFtZSBTcGFjZQ0KICAgICAgLSAgTGFiZWwgVHlwZSBOYW1lIFNwYWNlDQogICAgICAtICBG YWlsdXJlIFJlc3BvbnNlIE1lc3NhZ2UgTmFtZSBTcGFjZQ0KICAgICAgLSAgTW9kZWwgVHlwZSBO YW1lIFNwYWNlIA0KDQogICBUaGUgb25lIHdoaWNoIGNvdWxkIGJlIGludGVyZXN0aW5nIHRvIEFO Q1AsIGlzIHRoZSBNZXNzYWdlIFR5cGUgTmFtZQ0KICAgU3BhY2UgdGhhdCBHU01QdjMgZGl2aWRl cyBpbnRvIGZvdXIgcmFuZ2VzIGFzIGZvbGxvd3M6DQoNCg0KQXJiZXJnICAgICAgICAgICAgICAg ICBFeHBpcmVzIEF1Z3VzdCAxNywgMjAwOCAgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgIFZlbmRvciBTcGVjaWZpYyBNZXNzYWdlIGZvciBBTkNQICAgICAg IEZlYnJ1YXJ5IDIwMDgNCg0KDQogICAgICAtICBNZXNzYWdlIFR5cGVzIDAtOTkuDQogICAgICAg ICAgICAgIE1lc3NhZ2UgVHlwZXMgaW4gdGhpcyByYW5nZSBhcmUgcGFydCBvZiB0aGUgR1NNUHYz IGJhc2UNCiAgICAgICAgICAgICAgcHJvdG9jb2wuICBNZXNzYWdlIHR5cGVzIGluIHRoaXMgcmFu Z2UgYXJlIGFsbG9jYXRlZA0KICAgICAgICAgICAgICB0aHJvdWdoIGFuIElFVEYgY29uc2Vuc3Vz IGFjdGlvbiBbMTldLg0KDQogICAgICAtICBNZXNzYWdlIFR5cGVzIDEwMC0xOTkuDQogICAgICAg ICAgICAgIE1lc3NhZ2UgVHlwZXMgaW4gdGhpcyByYW5nZSBhcmUgU3BlY2lmaWNhdGlvbiBSZXF1 aXJlZA0KICAgICAgICAgICAgICBbMTldLiAgTWVzc2FnZSBUeXBlcyB1c2luZyB0aGlzIHJhbmdl IG11c3QgYmUgZG9jdW1lbnRlZA0KICAgICAgICAgICAgICBpbiBhbiBSRkMgb3Igb3RoZXIgcGVy bWFuZW50IGFuZCByZWFkaWx5IGF2YWlsYWJsZQ0KICAgICAgICAgICAgICByZWZlcmVuY2VzLg0K DQogICAgICAtICBNZXNzYWdlIFR5cGVzIDIwMC0yNDkuDQogICAgICAgICAgICAgIE1lc3NhZ2Ug VHlwZXMgaW4gdGhpcyByYW5nZSBhcmUgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZA0KICAgICAgICAg ICAgICBbMTldIGFuZCBhcmUgaW50ZW5kZWQgZm9yIEFic3RyYWN0IGFuZCBSZXNvdXJjZSBNb2Rl bA0KICAgICAgICAgICAgICBFeHRlbnNpb24gTWVzc2FnZXMuICBNZXNzYWdlIFR5cGVzIHVzaW5n IHRoaXMgcmFuZ2UgbXVzdA0KICAgICAgICAgICAgICBiZSBkb2N1bWVudGVkIGluIGFuIFJGQyBv ciBvdGhlciBwZXJtYW5lbnQgYW5kIHJlYWRpbHkNCiAgICAgICAgICAgICAgYXZhaWxhYmxlIHJl ZmVyZW5jZXMuDQoNCiAgICAgIC0gIE1lc3NhZ2UgVHlwZXMgMjUwLTI1NS4NCiAgICAgICAgICAg ICAgTWVzc2FnZSBUeXBlcyBpbiB0aGlzIHJhbmdlIGFyZSByZXNlcnZlZCBmb3IgdmVuZG9yDQog ICAgICAgICAgICAgIHByaXZhdGUgZXh0ZW5zaW9ucyBhbmQgYXJlIHRoZSByZXNwb25zaWJpbGl0 eSBvZg0KICAgICAgICAgICAgICBpbmRpdmlkdWFsIHZlbmRvcnMuICBJQU5BIG1hbmFnZW1lbnQg b2YgdGhpcyByYW5nZSBvZiB0aGUNCiAgICAgICAgICAgICAgTWVzc2FnZSBUeXBlIE5hbWUgU3Bh Y2UgaXMgdW5uZWNlc3NhcnkuDQoNCg0KNC4gIFZlbmRvciBzcGVjaWZpYyBtZXNzYWdlcyBpbiBB TkNQDQoNCiAgIFRoZSBwcm9wb3NhbCBpbiB0aGlzIGRvY3VtZW50IGlzIHRvIGRlZmluZSBhIG5l dyBjYXBhYmlsaXR5IHR5cGUgZm9yDQogICB2ZW5kb3Igc3BlY2lmaWMgZGF0YSBhcyBwYXJ0IG9m IHRoZSBBTkNQIHByb3RvY29sIGNhcGFiaWxpdHkgDQogICBuZWdvdGlhdGlvbnMsIGFuZCBmdXJ0 aGVyIG1vcmUgZGVmaW5lIGEgc2VwYXJhdGUgdmVuZG9yIHNwZWNpZmljIA0KICAgbWVzc2FnZSBl eHRlbnNpb24uDQoNCg0KNC4xIFZlbmRvciBTcGVjaWZpYyBDYXBhYmlsaXR5IE5lZ290aWF0aW9u IA0KDQogICBDYXBhYmlsaXR5IFR5cGUgOiBWZW5kb3ItU3BlY2lmaWMgRGF0YSA9IDB4MDYgKFRC RCkgIA0KDQogICBMZW5ndGggKGluIGJ5dGVzKSA6IG11bHRpcGx5IG9mIDQuIA0KICAgRXZlcnkg RW50ZXJwcmlzZSB3aXRoIHZlbmRvciBzcGVjaWZpYyBkYXRhIHN1cHBvcnRlZCB3aWxsIGFkZCA0 IA0KICAgYnl0ZXMgdG8gdGhlIGxlbmd0aCBmaWVsZC4NCg0KICAgQ2FwYWJpbGl0eSBEYXRhIDog bGlzdCBvZiBFbnRlcnByaXNlIG51bWJlcnMuDQogICAiRW50ZXJwcmlzZSBOdW1iZXJOIiBpcyBh IHZlbmRvcidzIEVudGVycHJpc2UgTnVtYmVyIGFzIHJlZ2lzdGVyZWQNCiAgIHdpdGggSUFOQSBb M10uICBJdCBpcyBhIGZvdXItYnl0ZSBpbnRlZ2VyIHZhbHVlIGluIG5ldHdvcmsgYnl0ZS0NCiAg IG9yZGVyLg0KDQoNCg0KDQoNCg0KDQpBcmJlcmcgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVn dXN0IDE3LCAyMDA4ICAgICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgVmVuZG9yIFNwZWNpZmljIE1lc3NhZ2UgZm9yIEFOQ1AgICAgICAgRmVicnVhcnkgMjAw OA0KDQoNCjQuMiBWZW5kb3IgU3BlY2lmaWMgRXh0ZW5zaW9ucw0KDQogICBHU01QdjMgWzFdICJW ZW5kb3IgU3BlY2lmaWMiIG1lc3NhZ2UgKHR5cGUgMjU1KSBNVVNUIGJlIHVzZWQgYnkgDQogICB0 aGUgQlJBUyBhbmQgdGhlIEFjY2VzcyBOb2RlIHRvIGV4Y2hhbmdlIHZlbmRvciBzcGVjaWZpYyBk YXRhDQogICBhcyBwYXJ0IG9mIHRoZSBBTkNQIHByb3RvY29sIGNvbW11bmljYXRpb24uDQoNCiAg IFRoZSBWZW5kb3IgU3BlY2lmaWMgbWVzc2FnZSB1c2VzIHRoZSBHU01QdjMgWzFdIGJhc2ljIGRl ZmluZWQNCiAgIG1lc3NhZ2UgZm9ybWF0IGFzIHNob3duIGJlbG93Og0KDQogICAgMCAgICAgICAg ICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAg IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMQ0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgVmVycyAgfCAgU3ViICB8IE1lc3NhZ2UgVHlwZSAg fCBSZXN1bHR8ICAgICAgICBDb2RlICAgICAgICAgICB8IA0KICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgUGFy dGl0aW9uIElEICB8ICAgICAgICAgICAgVHJhbnNhY3Rpb24gSWRlbnRpZmllciAgICAgICAgICAg ICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKw0KICAgfEl8ICAgICAgU3ViTWVzc2FnZSBOdW1iZXIgICAgICB8ICAg ICAgICAgICBMZW5ndGggICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgfiAgICAgICAgICAgICAgICAgICAgICAgICAgTWVzc2FnZSBCb2R5ICAgICAgICAgICAgICAg ICAgICAgICAgIH4NCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQoNCg0KICAgVGhlIE1lc3Nh Z2UgYm9keSBpbiB0aGUgQU5DUCB2ZW5kb3Igc3BlY2lmaWMgbWVzc2FnZSBNVVNUIGZvbGxvdw0K ICAgdGhlIGZvcm1hdCBzaG93biBiZWxvdzoNCg0KICAgMCAgICAgICAgICAgICAgICAgICAxICAg ICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KICAgfCBNZXNzYWdlIFR5cGUgIHwgICAgTGVuZ3RoICAgICB8ICAgICAgICBFbnRlcnBy aXNlIE51bWJlcjEgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgIERhdGFMZW4xICAgICB8ICAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgICAgICAgICAgICAgICsN CiAgIFwgICAgICAgICAgICAgICAgICAgICAgVmVuZG9yIFNwZWNpZmljIERhdGExICAgICAgICAg ICAgICAgICAgICBcDQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAgICAgICAgICAgICBFbnRl cnByaXNlIE51bWJlcjIgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8 ICBEYXRhTGVuMiAgICAgfCAgICAgICAgICAgVmVuZG9yIFNwZWNpZmljIERhdGEyICAgICAgICAg ICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcDQogICAuICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLg0KICAgLiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC4NCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rDQoNCg0KICAgVGhlIE1lc3NhZ2UgVHlwZSBmb3IgVmVuZG9yIFNwZWNp ZmljIG1lc3NhZ2VzIGlzIDI1NSAoVEJEKS4NCg0KDQoNCg0KQXJiZXJnICAgICAgICAgICAgICAg ICBFeHBpcmVzIEF1Z3VzdCAxNywgMjAwOCAgICAgICAgICAgICAgICAgIFtQYWdlIDRdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgIFZlbmRvciBTcGVjaWZpYyBNZXNzYWdlIGZvciBBTkNQICAgICAg IEZlYnJ1YXJ5IDIwMDgNCg0KDQogICBUaGUgb25lLWJ5dGUgTGVuZ3RoIGZpZWxkIGlzIHRoZSBs ZW5ndGggb2YgdGhlIGRhdGEgY2FycmllZCBpbiB0aGUNCiAgIE1lc3NhZ2UgQm9keSBpbiBieXRl cy4gIFRoZSBsZW5ndGggaW5jbHVkZXMgdGhlIGxlbmd0aCBvZiB0aGUgZmlyc3QNCiAgIEVudGVy cHJpc2UgTnVtYmVyOyB0aGUgbWluaW11bSBsZW5ndGggaXMgNCBieXRlcy4NCg0KICAgIkVudGVy cHJpc2UgTnVtYmVyTiIgaXMgYSB2ZW5kb3IncyBFbnRlcnByaXNlIE51bWJlciBhcyByZWdpc3Rl cmVkDQogICB3aXRoIElBTkEgWzNdLiAgSXQgaXMgYSBmb3VyLWJ5dGUgaW50ZWdlciB2YWx1ZSBp biBuZXR3b3JrIGJ5dGUtDQogICBvcmRlci4gVGhlIEVudGVycHJpc2UgbnVtYmVyIHVzZWQgaW4g dGhlIFZlbmRvciBTcGVjaWZpYyBtZXNzYWdlDQogICBNVVNUIG1hdGNoIHRoZSBudW1iZXJzIGFn cmVlZCB1cG9uIGluIHRoZSBjYXBhYmlsaXR5IG5lZ290aWF0aW9uLg0KICAgSWYgYW4gRW50ZXJw cmlzZSBudW1iZXIgdXNlZCBpbiB0aGUgVmVuZG9yIFNwZWNpZmljIE1lc3NhZ2UgQm9keSBpcw0K ICAgZGlmZmVyZW50IGZyb20gdGhlIGNhcGFiaWxpdHkgbmVnb3RpYXRpb25zIHRoZW4gdGhlIHZl bmRvciBzcGVjaWZpYw0KICAgZGF0YSBmb3IgdGhpcyBFbnRlcnByaXNlIG51bWJlciBNQVkgc2ls ZW50bHkgYmUgZGlzY2FyZCBieSB0aGUgDQogICByZWNlaXZlci4NCg0KICAgRGF0YUxlbk4gaXMg dGhlIGxlbmd0aCBvZiB0aGUgZGF0YSBhc3NvY2lhdGVkIHdpdGggdGhlIEVudGVycHJpc2UNCiAg IE51bWJlci4NCg0KICAgVGhlIFZlbmRvciBTcGVjaWZpYyBEYXRhIGlzIGFuIG9wYXF1ZSBzZXF1 ZW5jZSBvZiBieXRlcy4NCg0KICAgVGhlIFZlbmRvci1TcGVjaWZpYyBNZXNzYWdlIGluY2x1ZGVz IGF0IGxlYXN0IG9uZSBFbnRlcnByaXNlIE51bWJlcg0KICAgYW5kIGNhcnJpZXMgb3BhcXVlIGRh dGEgZGVmaW5lZCBieSB0aGUgb3JnYW5pemF0aW9uIGlkZW50aWZpZWQgYnkgDQogICB0aGUgRW50 ZXJwcmlzZSBOdW1iZXIuIFRoZSBBTkNQIGVuZCBub2RlLCBBY2Nlc3MgTm9kZSBvciBCUkFTLCBN QVkNCiAgIGluY2x1ZGUgZGF0YSBhc3NvY2lhdGVkIHdpdGggbW9yZSB0aGFuIG9uZSB2ZW5kb3In cyBFbnRlcnByaXNlIA0KICAgTnVtYmVyIHdpdGhpbiBhIHNpbmdsZSBpbnN0YW5jZSBvZiB0aGUg VmVuZG9yIFNwZWNpZmljIE1lc3NhZ2UuDQoNCiAgIE9mIGNvdXJzZSwgdGhlIFZlbmRvci1TcGVj aWZpYyBkYXRhIGFyZSB2ZW5kb3Itc3BlY2lmaWMuIFRoaXMNCiAgIHNwZWNpZmljYXRpb24gZG9l cyBub3QgZXN0YWJsaXNoIGFueSByZXF1aXJlbWVudHMgb24gdGhlIGRhdGEgaW4gdGhlDQogICBt ZXNzYWdlLiBWZW5kb3JzIHdobyBtYWtlIHVzZSBvZiB0aGlzIG1lc3NhZ2UgdHlwZSBhcmUgZW5j b3VyYWdlZCB0bw0KICAgZG9jdW1lbnQgdGhlaXIgdXNhZ2UgaW4gb3JkZXIgdG8gbWFrZSBpbnRl cm9wZXJhYmlsaXR5IHBvc3NpYmxlLg0KDQoNCjUuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0K DQogICBUaGUgQlJBUyBhbmQgRFNMQU1zIGFyZSBpbXBsaWNpdGx5IGluIGEgdHJ1c3RlZCBkb21h aW4sIHNvIHNlY3VyaXR5IA0KICAgZm9yIHZlbmRvciBzcGVjaWZpYyBtZXNzYWdlcyBpbiBBTkNQ IGRvIG5vdCBwdXQgZm9ydGggb3RoZXIgc2VjdXJpdHkNCiAgIGNvbnNpZGVyYXRpb25zIG5vdCBh bHJlYWR5IG1lbnRpb25lZCBpbiB0aGUgQU5DUCBQcm90b2NvbCBkcmFmdCBbMl0uDQoNCg0KNi4g IElBTkEgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IGNh cGFiaWxpdHkgdHlwZSBhcyB3ZWxsIGFzIGEgbmV3IG1lc3NhZ2UNCiAgIHR5cGUgd2hpY2ggbmVl ZCB0byBiZSByZXNlcnZlZCB3aXRoIElBTkEsIGFzIHBhcnQgb2YgdGhlIG92ZXJhbGwNCiAgIEFO Q1AgUHJvdG9jb2wgWzJdIElBTkEgcmVzZXJ2YXRpb24uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkFy YmVyZyAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMTcsIDIwMDggICAgICAgICAgICAg ICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBWZW5kb3IgU3BlY2lmaWMgTWVz c2FnZSBmb3IgQU5DUCAgICAgICBGZWJydWFyeSAyMDA4DQoNCg0KNy4gIFJlZmVyZW5jZXMNCg0K Ny4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgWzFdICAgRG9yaWEsIEEuIGV0IGFsLCAi R2VuZXJhbCBTd2l0Y2ggTWFuYWdlbWVudCBQcm90b2NvbCAtIFYzIiANCiAgICAgICAgIChHU01Q djMpLCBSRkMgMzI5MiwgSnVuZSAyMDAyLiANCg0KICAgWzJdICAgUy4gV2FkaHdhLCBKLiBNb2lz YW5kLCAuLiAiIFByb3RvY29sIGZvciBBY2Nlc3MgTm9kZSBDb250cm9sIA0KICAgICAgICAgTWVj aGFuaXNtIGluIEJyb2FkYmFuZCBOZXR3b3JrcyIsIGRyYWZ0LWlldGYtYW5jcC1wcm90b2NvbC0N CiAgICAgICAgIDAyLnR4dCANCg0KICAgWzNdICBJQU5BLCAiUHJpdmF0ZSBFbnRlcnByaXNlIE51 bWJlcnMgKGh0dHA6Ly93d3cuaWFuYS5vcmcvDQogICAgICAgIGFzc2lnbm1lbnRzL2VudGVycHJp c2UtbnVtYmVycy5odG1sKSIuDQoNCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29y ZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQogICAgICAgICAgICAgIFJlcXVpcmVtZW50 IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoNCg0KQXV0aG9ycycgQWRk cmVzc2VzDQoNCiAgIFBldGVyIEFyYmVyZyANCiAgIFJlZGJhY2sgTmV0d29ya3MgYW4gRXJpY3Nz b24gQ29tcGFueQ0KICAgMzAwIEhvbGdlciBXYXkNCiAgIFNhbiBKb3NlLCBDQSA5NTEzNA0KICAg VVNBDQogICBFbWFpbDogcGFyYmVyZ0ByZWRiYWNrLmNvbQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkFyYmVyZyAgICAgICAgICAgICAgICAgRXhw aXJlcyBBdWd1c3QgMTcsIDIwMDggICAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICBWZW5kb3IgU3BlY2lmaWMgTWVzc2FnZSBmb3IgQU5DUCAgICAgICBGZWJy dWFyeSAyMDA4DQoNCg0KRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgIENvcHlyaWdodCAo QykgVGhlIElFVEYgVHJ1c3QgKDIwMDgpLg0KDQogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3Qg dG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucw0KICAgY29udGFpbmVkIGlu IEJDUCA3OCwgYW5kIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMNCiAg IHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLg0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJUyIg YmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVT RU5UUw0KICAgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVU WSwgVEhFIElFVEYgVFJVU1QgQU5EDQogICBUSEUgSU5URVJORVQgRU5HSU5FRVJJTkcgVEFTSyBG T1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUw0KICAgT1IgSU1QTElFRCwgSU5D TFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GDQog ICBUSEUgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1Ig QU5ZIElNUExJRUQNCiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1Mg Rk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLg0KDQoNCkludGVsbGVjdHVhbCBQcm9wZXJ0eQ0KDQog ICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNj b3BlIG9mIGFueQ0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdo dHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvDQogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRh dGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluDQogICB0aGlzIGRvY3Vt ZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMN CiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2Vu dCB0aGF0IGl0IGhhcw0KICAgbWFkZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5 IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uDQogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRo IHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlDQogICBmb3VuZCBpbiBC Q1AgNzggYW5kIEJDUCA3OS4NCg0KICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRv IHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkNCiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMg dG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4NCiAgIGF0dGVtcHQgbWFk ZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBv Zg0KICAgc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9m IHRoaXMNCiAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24t bGluZSBJUFIgcmVwb3NpdG9yeSBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuDQoNCiAg IFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0 dGVudGlvbiBhbnkNCiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9u cywgb3Igb3RoZXIgcHJvcHJpZXRhcnkNCiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9s b2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudA0KICAgdGhpcyBzdGFuZGFyZC4g IFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdA0KICAgaWV0Zi1p cHJAaWV0Zi5vcmcuDQoNCg0KQWNrbm93bGVkZ21lbnQNCg0KICAgRnVuZGluZyBmb3IgdGhlIFJG QyBFZGl0b3IgZnVuY3Rpb24gaXMgcHJvdmlkZWQgYnkgdGhlIElFVEYNCiAgIEFkbWluaXN0cmF0 aXZlIFN1cHBvcnQgQWN0aXZpdHkgKElBU0EpLg0KDQoNCg0KDQpBcmJlcmcgICAgICAgICAgICAg ICAgIEV4cGlyZXMgQXVndXN0IDE3LCAyMDA4ICAgICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwN Cg== --_004_48C276B536524E478C659685995F6AA527656DB671RBSJXadredbac_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp --_004_48C276B536524E478C659685995F6AA527656DB671RBSJXadredbac_-- From ancp-bounces@ietf.org Tue Feb 19 04:50:51 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01F3F28C54E; Tue, 19 Feb 2008 04:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bK7qXnOMDr0g; Tue, 19 Feb 2008 04:50:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9069428C573; Tue, 19 Feb 2008 04:50:49 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 286CC28C587 for ; Tue, 19 Feb 2008 04:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEsn4reTPzd0 for ; Tue, 19 Feb 2008 04:50:46 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 1EC7028C573 for ; Tue, 19 Feb 2008 04:50:46 -0800 (PST) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Tue, 19 Feb 2008 13:50:42 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Feb 2008 13:50:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 13:50:42 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C81F782@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <47B94869.8030905@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] missing items in the ancp-mib draft Thread-Index: AchyDEi3LTX8ok1rSiGceX2NeL5ObgAySHaw References: <1B6169C658325341A3B8066E23919E1C81F76F@S4DE8PSAANK.mitte.t-com.de> <47B55F0E.7040205@alcatel-lucent.be> <83153A1EB675AF4F82E134FA27F95F6702F354FA@ilptex01.ecitele.com> <47B94869.8030905@alcatel-lucent.be> From: "Freudenberger, Markus" To: , X-OriginalArrivalTime: 19 Feb 2008 12:50:42.0385 (UTC) FILETIME=[09507C10:01C872F6] Cc: "Haag, T" , "Busser, M" , ancp@ietf.org Subject: Re: [ANCP] missing items in the ancp-mib draft X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Moti, Stefaan, I agree with Moti's comments. = See my further comments to Stefaans statemtens inline, marked with "[MF]". Are there views from other people? regards Markus = -----Urspr=FCngliche Nachricht----- Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] = Gesendet: Montag, 18. Februar 2008 09:57 An: Moti Morgenstern; Freudenberger, Markus Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org Betreff: Re: [ANCP] missing items in the ancp-mib draft Moti, Markus, Moti Morgenstern wrote: > Hi, > = > I think what Markus wrote is pretty correct. There should be, for example= , a MIB for associating ANCP session with "ANCP VLAN". So, if that MIB is a= lready available, in already existing RFCs, then the ANCP MIB should includ= e a section describing that as part of the "Relationship to Other MIB Modul= es", as done with the interfaces MIB. That will allow software engineers (e= ven if not members in our honorable ANCP WG) to see the whole picture. Howe= ver, if such a MIB is not available, then obviously the ANCP MIB should des= cribe what is the gap and define the MIB for filling it. = > = > More specifically (and please correct me if I'm wrong): > - I do not recall a MIB for ATM PVCs that assumes single VC with multiple= xed services. However, in this case I think that we do not need such a MIB = because the ANCP control channel should actually be associated with bridge = port (and that bridge port has a MIB that provides the information on the u= nderlying L2). The question is how does the EMS associate the ANCP control = channel with a specific bridge port? An informational text can be added to explain how IP/ANCP packets are to be= routed but there is no formal linking with any other MIB. How the IP laye= r is configured is independent from how the protocol is configured. [MF] = Stefaan, do you mean it is independent because ANCP is one of many other ap= plications which uses IP? If yes, you are right but the IP layer is essenti= al for ANCP (as the architecture chooses TCP/IP as a tranpsort medium) and = as a consequence it is also essential to configure it and associate it with= a certain ANCP session from an EMS. This has to be mentioned somehow in th= e document. I don't see a problem to create a reference to an RFC and/or a = MIB which provides these capabilities. But it is still needed to define th= e link between the IP layer and ANCP session. [MF] For me it is also fine that ANCP packets are not routed in the AN but that = ANCP is bound to a certain interface (=3DVLAN or PVC) like it is for instan= ce with OSPF. But then the configured NAS IP address in the AN must be a d= irectly attached IP address, if the NAS IP address is not directly attached= , then the AN does not know which IP address to ARP (which it normally gets= from the next-hop of the matching route). When ANCP bypasses routing, VLAN-ID or PVC (with some extra attributes only= specific for ANCP packets like for instance p-bits) could be configured in= ancpAnSessionConfigTable. For me both options are fine, but if the second option is selected, the the= framework draft should also mention this limitation (which should not be a= problem if we all agree I suspect). [MF] = Sorry but I cannot indicate the options. Which limitation do you mean? = Anyway, I think the ANCP packets are not routed in the AN, they are termina= ted and the next IP hop is the NAS. The ancp framework document states for = this purpose: ... o Control Channel: a bidirectional IP communication interface between the controller function (in the NAS) and the reporting/ enforcement function (in the AN). It is assumed that this interface is configured (rather than discovered) on the AN and the NAS. ... and ... o The Control Channel MUST be terminated at the Access Node. ... To summarize, I only see the option to add additional attributes into the a= ncpAnSessionConfigTable for layer 2 connection parameters (VLAN, VCC, QoS c= lass, priority) per session. = [MF] What is your preference? > - Stefaan says that "ANCP are IP packets originated from an IP address in= the AN" and that's correct. But how does the EMS configure that address? H= ow does the EMS associate it with one of possibly multiple sessions? > = It is the IP routing table that associates an ANCP packet (IP packet) to a = certain outgoing interface. The AN IP address is not configured per sessio= n but you can see the selected IP address in ancpAnCurrentSessionTable. Ty= pically, when a device generates an IP packet, its IP source address is usu= ally set to the IP address of the outgoing IP interface. When the AN only = has 1 IP address (after all it is not a router), then it is straitforward. [MF] I disagree, the AN has more than 1 IP address (e. g. for telnet/SNMP), so w= e have to differentiate here and if one can see the IP addess for a session= in the ancpAnCurrentSessionTable, someone has to configure it somewhere, r= ight? = [MF] regards, Stefaan > I'll be glad to hear more opinions on those issues. > = > Regards, > Moti > = > = > -----Original Message----- > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = > Of Stefaan DE CNODDER > Sent: Friday, February 15, 2008 11:45 AM > To: Freudenberger, Markus > Cc: Haag, T; Busser,M; ancp@ietf.org > Subject: Re: [ANCP] missing items in the ancp-mib draft > = > = > Hi Markus, > = > The parameters related to control channel has been intentionally not = > been included in the ANCP MIB because these attributes are to be = > configured in other MIBs. For instance, if the VLAN on which ANCP is = > running needs p-bit 5, then that is to be configured in the = > corresponding ethernet MIB where VLANs are configured. The same for > PVCs: I guess there are ATM MIBs where the attributes of all the PVCs = > can be configured. > = > Then you also need the selection of the VLAN or PVC to be used for ANCP. = > Actually, ANCP are IP packets originated from an IP address in the = > AN, and transmitted like any other IP packet, i.e., the AN performs an = > IP lookup in its routing table. So if the correct routing cannot be = > achieved because the IP address of the directly attached interface of = > the "ANCP VLAN" is not used as NAS address, then an appriopriate route = > has to be configured such that these packets are going to the VLAN on = > which they should be. However, also this "routing information" (in = > whatever form) is to be configured in other MIBs than the ANCP MIB. > = > Look it like this in case of ethernet: if the AN generates an ANCP = > message to the NAS, then the ANCP message is put in an ethernet frame, = > this ethernet frame needs a MAC destination address. To get the MAC = > destination address, the AN has to send an ARP to an IP address. This = > IP address is the next-hop IP address, which it gets from the routing = > information. It can be a next-hop of a route, or in case the NAS IP = > address is directly attached, the IP packet matches the direct route. > = > So I have the feeling that this "routing information" for ANCP can = > exist in multiple forms: > (1) a route with next-hop, or directly attached > (2) a VLAN (so no next-hop and then the NAS IP must be directly = > attached for sending an ARP). > - ... > = > So I have the feeling that this just do not belong to an ANCP MIB. = > For sure option (1) should not be in the ANCP MIB, (2) could be added = > but since a generic solution anyhow requires (1), I do not see the = > need to add something in the ANCP MIB. > = > Extra filters in the ANCP MIB could be added like for instance that = > ANCP messages may only be sent or received on particular VLANs, but = > that is just an extra ACL, and each implementation can add as much = > security as needed and this should maybe not be in a standard ANCP MIB. > = > Do you agree with this? > = > Thanks for the review, all comments are very welcome. > = > regards, > Stefaan > = > = > Freudenberger, Markus wrote: > = >>Hi all, >> >>looking into the actual ancp-mib draft, I am misssing the following: >> >>1) the possibilty to configure the IP address on the AN for the control c= hannel as it is already defined for the peer NAS. This implies adding addit= ional entries into the ancpAnCurrentSessionTable for reading the control ch= annel ip address of the NAS. >> >>2) the possibility to configure the allocation of control channel(s) to a= physical interface with VPI/VCI resp. C-/S-VAN-ID values and Qos/CoS setti= ng. = >> >>Both is required to allow the EMS the setup of the control channel with S= NMP and this is described in Section 6 of the ancp framework document anywa= y (See below). = >> >>----------------------- snip from draft-ietf-ancp-framework-04.txt = >>----------------------- 6. Management Related Requirements >> >> o It must be possible to configure the following parameters on the >> Access Node and the NAS: >> >> * Parameters related to the Control Channel transport method: >> these include the VPI/VCI and transport characteristics (e.g. >> VBR-rt or CBR) for ATM networks or the C-VLAN ID and S-VLAN ID >> and p-bit marking for Ethernet networks; >> >> * Parameters related to the Control Channel itself: these include >> the IP address of the IP interface on the Access Node and the >> NAS >>----------------------- snip from draft-ietf-ancp-framework-04.txt = >>----------------------- >> >>Any comments? >> >>Regards >>Markus Freudenberger >> >>T-Systems Enterprise Services GmbH >>Systems Integration >>Telco Project & Design >>Line of Business Networks & Processes >>Technology Consultant >>Deutsche-Telekom-Allee 7, D-64295 Darmstadt >>+49 6151 937-3679 (Phone) >>+49 6151 937-19875 (Fax) >>+49 521 5224 5816 (PC-Fax) >>E-Mail: mailto:markus.freudenberger@t-systems.com >>Internet: http://t-systems.com >> >> >> >>>T-Systems Enterprise Services GmbH >>>Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: = >>>Reinhard Clemens (Vorsitzender)*, Helmut Binder, Albert Henn, Olaf = >>>Heyden*, Katrin Horstmann, Wilfried Peters*, Dr. Herbert Schaaff*, = >>>Zvezdana Seeger* >>>Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der = >>>Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 = >>>*Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG >>> >> >>Notice: This transmittal and/or attachments may be privileged or confiden= tial. If you are not the intended recipient, you are hereby notified that y= ou have received this transmittal in error; any review, dissemination, or c= opying is strictly prohibited. If you received this transmittal in error, p= lease notify us immediately by reply and immediately delete this message an= d all its attachments. Thank you. >>T-Systems - Business flexibility >> >> >>_______________________________________________ >>ANCP mailing list >>ANCP@ietf.org >>http://www.ietf.org/mailman/listinfo/ancp > = > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > http://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Feb 19 06:03:38 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04C2E28C5D1; Tue, 19 Feb 2008 06:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.257 X-Spam-Level: X-Spam-Status: No, score=-0.257 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFcu7+ZR094a; Tue, 19 Feb 2008 06:03:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD0328C5C7; Tue, 19 Feb 2008 06:03:36 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E795828C5C9 for ; Tue, 19 Feb 2008 06:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stEB-MMnMfD7 for ; Tue, 19 Feb 2008 06:03:33 -0800 (PST) Received: from smail6.alcatel.fr (colt-na7.alcatel.fr [62.23.212.7]) by core3.amsl.com (Postfix) with ESMTP id CC2DC28C591 for ; Tue, 19 Feb 2008 06:03:32 -0800 (PST) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m1JE1EDv024801; Tue, 19 Feb 2008 15:01:15 +0100 Received: from [172.31.131.165] ([172.31.131.165]) by FRVELSBHS02.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Tue, 19 Feb 2008 15:02:58 +0100 Message-ID: <47BAE191.5040406@alcatel-lucent.be> Date: Tue, 19 Feb 2008 15:02:57 +0100 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: "Freudenberger, Markus" References: <1B6169C658325341A3B8066E23919E1C81F76F@S4DE8PSAANK.mitte.t-com.de> <47B55F0E.7040205@alcatel-lucent.be> <83153A1EB675AF4F82E134FA27F95F6702F354FA@ilptex01.ecitele.com> <47B94869.8030905@alcatel-lucent.be> <1B6169C658325341A3B8066E23919E1C81F782@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1B6169C658325341A3B8066E23919E1C81F782@S4DE8PSAANK.mitte.t-com.de> X-OriginalArrivalTime: 19 Feb 2008 14:02:58.0699 (UTC) FILETIME=[21F57DB0:01C87300] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "Haag, T" , "Busser, M" , ancp@ietf.org Subject: Re: [ANCP] missing items in the ancp-mib draft X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi Markus, Indeed, ANCP is just one application that uses IP, and as soon the ANCP = packet is encapsulated into an IP packet, it goes to the IP layer where = it is treated like any other IP packet. Suppose in ancpAnSessionConfigTable, an attribute VLAN is added, and I = configure this VLAN equal to 100. Ok, the AN can sent then the ANCP = packet to VLAN 100 (even though the IP routing table says that the best = path to the NAS IP address is via another VLAN), then my question is: = what will be the MAC destination address of this IP packet, i.e., to = which IP address has the AN to send an ARP request to learn the MAC = destination address to be used for the ANCP packet? Knowing the VLAN ID = is just not sufficient according to me. Either the NAS IP address MUST = be in the subnet as the configured VLAN (in which case the ARP is = directly to the NAS IP address), or an IP lookup is done that results in = a next-hop with corresponding outgoing interface (=3DVLAN, PVC, ...). In = the latter case, no VLAN is needed in ancpAnSessionConfigTable because = the IP lookup will automatically give the VLAN. For me both options are Ok, I just want to know how it has to work. regards, Stefaan Freudenberger, Markus wrote: > Moti, Stefaan, > = > I agree with Moti's comments. = > See my further comments to Stefaans statemtens inline, marked with "[MF]". > = > Are there views from other people? > = > regards > Markus = > = > -----Urspr=FCngliche Nachricht----- > Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] = > Gesendet: Montag, 18. Februar 2008 09:57 > An: Moti Morgenstern; Freudenberger, Markus > Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org > Betreff: Re: [ANCP] missing items in the ancp-mib draft > = > = > Moti, Markus, > = > Moti Morgenstern wrote: > = > = >>Hi, >> >>I think what Markus wrote is pretty correct. There should be, for example= , a MIB for associating ANCP session with "ANCP VLAN". So, if that MIB is a= lready available, in already existing RFCs, then the ANCP MIB should includ= e a section describing that as part of the "Relationship to Other MIB Modul= es", as done with the interfaces MIB. That will allow software engineers (e= ven if not members in our honorable ANCP WG) to see the whole picture. Howe= ver, if such a MIB is not available, then obviously the ANCP MIB should des= cribe what is the gap and define the MIB for filling it. = >> >>More specifically (and please correct me if I'm wrong): >>- I do not recall a MIB for ATM PVCs that assumes single VC with multiple= xed services. However, in this case I think that we do not need such a MIB = because the ANCP control channel should actually be associated with bridge = port (and that bridge port has a MIB that provides the information on the u= nderlying L2). The question is how does the EMS associate the ANCP control = channel with a specific bridge port? > = > = > An informational text can be added to explain how IP/ANCP packets are to = be routed but there is no formal linking with any other MIB. How the IP la= yer is configured is independent from how the protocol is configured. > = > [MF] = > Stefaan, do you mean it is independent because ANCP is one of many other = applications which uses IP? If yes, you are right but the IP layer is essen= tial for ANCP (as the architecture chooses TCP/IP as a tranpsort medium) an= d as a consequence it is also essential to configure it and associate it wi= th a certain ANCP session from an EMS. This has to be mentioned somehow in = the document. I don't see a problem to create a reference to an RFC and/or = a MIB which provides these capabilities. But it is still needed to define = the link between the IP layer and ANCP session. > [MF] > = > = > For me it is also fine that ANCP packets are not routed in the AN but tha= t ANCP is bound to a certain interface (=3DVLAN or PVC) like it is for inst= ance with OSPF. But then the configured NAS IP address in the AN must be a= directly attached IP address, if the NAS IP address is not directly attach= ed, then the AN does not know which IP address to ARP (which it normally ge= ts from the next-hop of the matching route). > = > When ANCP bypasses routing, VLAN-ID or PVC (with some extra attributes on= ly specific for ANCP packets like for instance p-bits) could be configured = in ancpAnSessionConfigTable. > = > For me both options are fine, but if the second option is selected, the t= he framework draft should also mention this limitation (which should not be= a problem if we all agree I suspect). > = > [MF] = > Sorry but I cannot indicate the options. Which limitation do you mean? = > Anyway, I think the ANCP packets are not routed in the AN, they are termi= nated and the next IP hop is the NAS. The ancp framework document states fo= r this purpose: > ... > o Control Channel: a bidirectional IP communication interface > between the controller function (in the NAS) and the reporting/ > enforcement function (in the AN). It is assumed that this > interface is configured (rather than discovered) on the AN and the > NAS. > ... > and > ... > o The Control Channel MUST be terminated at the Access Node. > ... > = > To summarize, I only see the option to add additional attributes into the= ancpAnSessionConfigTable for layer 2 connection parameters (VLAN, VCC, QoS= class, priority) per session. = > [MF] > = > What is your preference? > = > = > = >>- Stefaan says that "ANCP are IP packets originated from an IP address in= the AN" and that's correct. But how does the EMS configure that address? H= ow does the EMS associate it with one of possibly multiple sessions? >> > = > = > It is the IP routing table that associates an ANCP packet (IP packet) to = a certain outgoing interface. The AN IP address is not configured per sess= ion but you can see the selected IP address in ancpAnCurrentSessionTable. = Typically, when a device generates an IP packet, its IP source address is u= sually set to the IP address of the outgoing IP interface. When the AN onl= y has 1 IP address (after all it is not a router), then it is straitforward. > = > [MF] > I disagree, the AN has more than 1 IP address (e. g. for telnet/SNMP), so= we have to differentiate here and if one can see the IP addess for a sessi= on in the ancpAnCurrentSessionTable, someone has to configure it somewhere,= right? = > [MF] > = > regards, > Stefaan > = > = > = >>I'll be glad to hear more opinions on those issues. >> >>Regards, >>Moti >> >> >>-----Original Message----- >>From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = >>Of Stefaan DE CNODDER >>Sent: Friday, February 15, 2008 11:45 AM >>To: Freudenberger, Markus >>Cc: Haag, T; Busser,M; ancp@ietf.org >>Subject: Re: [ANCP] missing items in the ancp-mib draft >> >> >>Hi Markus, >> >>The parameters related to control channel has been intentionally not = >>been included in the ANCP MIB because these attributes are to be = >>configured in other MIBs. For instance, if the VLAN on which ANCP is = >>running needs p-bit 5, then that is to be configured in the = >>corresponding ethernet MIB where VLANs are configured. The same for >>PVCs: I guess there are ATM MIBs where the attributes of all the PVCs = >>can be configured. >> >>Then you also need the selection of the VLAN or PVC to be used for ANCP. = >> Actually, ANCP are IP packets originated from an IP address in the = >>AN, and transmitted like any other IP packet, i.e., the AN performs an = >>IP lookup in its routing table. So if the correct routing cannot be = >>achieved because the IP address of the directly attached interface of = >>the "ANCP VLAN" is not used as NAS address, then an appriopriate route = >>has to be configured such that these packets are going to the VLAN on = >>which they should be. However, also this "routing information" (in = >>whatever form) is to be configured in other MIBs than the ANCP MIB. >> >>Look it like this in case of ethernet: if the AN generates an ANCP = >>message to the NAS, then the ANCP message is put in an ethernet frame, = >>this ethernet frame needs a MAC destination address. To get the MAC = >>destination address, the AN has to send an ARP to an IP address. This = >>IP address is the next-hop IP address, which it gets from the routing = >>information. It can be a next-hop of a route, or in case the NAS IP = >>address is directly attached, the IP packet matches the direct route. >> >>So I have the feeling that this "routing information" for ANCP can = >>exist in multiple forms: >>(1) a route with next-hop, or directly attached >>(2) a VLAN (so no next-hop and then the NAS IP must be directly = >>attached for sending an ARP). >>- ... >> >>So I have the feeling that this just do not belong to an ANCP MIB. = >>For sure option (1) should not be in the ANCP MIB, (2) could be added = >>but since a generic solution anyhow requires (1), I do not see the = >>need to add something in the ANCP MIB. >> >>Extra filters in the ANCP MIB could be added like for instance that = >>ANCP messages may only be sent or received on particular VLANs, but = >>that is just an extra ACL, and each implementation can add as much = >>security as needed and this should maybe not be in a standard ANCP MIB. >> >>Do you agree with this? >> >>Thanks for the review, all comments are very welcome. >> >>regards, >>Stefaan >> >> >>Freudenberger, Markus wrote: >> >> >>>Hi all, >>> >>>looking into the actual ancp-mib draft, I am misssing the following: >>> >>>1) the possibilty to configure the IP address on the AN for the control = channel as it is already defined for the peer NAS. This implies adding addi= tional entries into the ancpAnCurrentSessionTable for reading the control c= hannel ip address of the NAS. >>> >>>2) the possibility to configure the allocation of control channel(s) to = a physical interface with VPI/VCI resp. C-/S-VAN-ID values and Qos/CoS sett= ing. = >>> >>>Both is required to allow the EMS the setup of the control channel with = SNMP and this is described in Section 6 of the ancp framework document anyw= ay (See below). = >>> >>>----------------------- snip from draft-ietf-ancp-framework-04.txt = >>>----------------------- 6. Management Related Requirements >>> >>> o It must be possible to configure the following parameters on the >>> Access Node and the NAS: >>> >>> * Parameters related to the Control Channel transport method: >>> these include the VPI/VCI and transport characteristics (e.g. >>> VBR-rt or CBR) for ATM networks or the C-VLAN ID and S-VLAN ID >>> and p-bit marking for Ethernet networks; >>> >>> * Parameters related to the Control Channel itself: these include >>> the IP address of the IP interface on the Access Node and the >>> NAS >>>----------------------- snip from draft-ietf-ancp-framework-04.txt = >>>----------------------- >>> >>>Any comments? >>> >>>Regards >>>Markus Freudenberger >>> >>>T-Systems Enterprise Services GmbH >>>Systems Integration >>>Telco Project & Design >>>Line of Business Networks & Processes >>>Technology Consultant >>>Deutsche-Telekom-Allee 7, D-64295 Darmstadt >>>+49 6151 937-3679 (Phone) >>>+49 6151 937-19875 (Fax) >>>+49 521 5224 5816 (PC-Fax) >>>E-Mail: mailto:markus.freudenberger@t-systems.com >>>Internet: http://t-systems.com >>> >>> >>> >>> >>>>T-Systems Enterprise Services GmbH >>>>Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: = >>>>Reinhard Clemens (Vorsitzender)*, Helmut Binder, Albert Henn, Olaf = >>>>Heyden*, Katrin Horstmann, Wilfried Peters*, Dr. Herbert Schaaff*, = >>>>Zvezdana Seeger* >>>>Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der = >>>>Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 = >>>>*Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG >>>> >>> >>>Notice: This transmittal and/or attachments may be privileged or confide= ntial. If you are not the intended recipient, you are hereby notified that = you have received this transmittal in error; any review, dissemination, or = copying is strictly prohibited. If you received this transmittal in error, = please notify us immediately by reply and immediately delete this message a= nd all its attachments. Thank you. >>>T-Systems - Business flexibility >>> >>> >>>_______________________________________________ >>>ANCP mailing list >>>ANCP@ietf.org >>>http://www.ietf.org/mailman/listinfo/ancp >> >>_______________________________________________ >>ANCP mailing list >>ANCP@ietf.org >>http://www.ietf.org/mailman/listinfo/ancp > = > = _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Feb 19 06:53:13 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37F1C28C27E; Tue, 19 Feb 2008 06:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmkrN1qnLGhf; Tue, 19 Feb 2008 06:53:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B16DB3A6A9D; Tue, 19 Feb 2008 06:53:11 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5DC63A6A7E for ; Tue, 19 Feb 2008 06:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnEdpxvRFTtb for ; Tue, 19 Feb 2008 06:53:09 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 76C223A69A8 for ; Tue, 19 Feb 2008 06:53:08 -0800 (PST) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Tue, 19 Feb 2008 15:53:02 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Feb 2008 15:53:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 15:53:01 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C81F785@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <47BAE191.5040406@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] missing items in the ancp-mib draft Thread-Index: AchzAESWfpOMEdmtRxuVI2LUqkgOAwAAKvpQ References: <1B6169C658325341A3B8066E23919E1C81F76F@S4DE8PSAANK.mitte.t-com.de><47B55F0E.7040205@alcatel-lucent.be><83153A1EB675AF4F82E134FA27F95F6702F354FA@ilptex01.ecitele.com><47B94869.8030905@alcatel-lucent.be><1B6169C658325341A3B8066E23919E1C81F782@S4DE8PSAANK.mitte.t-com.de> <47BAE191.5040406@alcatel-lucent.be> From: "Freudenberger, Markus" To: X-OriginalArrivalTime: 19 Feb 2008 14:53:02.0354 (UTC) FILETIME=[2046DF20:01C87307] Cc: "Haag, T" , "Busser, M" , ancp@ietf.org Subject: Re: [ANCP] missing items in the ancp-mib draft X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi Stefaan, the ancp session runs in the subnet as the configured VLAN. Example configuration: = AN NAS ----------------------------------- Bridge-port 1 1 S-VLAN-ID 10 10 C-VLAN-ID 10 10 prio 7 7 VPI 32 32 = VCI 32 32 QoS CBR CBR IP-address 192.168.0.1/30 192.168.0.2/30 ... regards Markus = -----Urspr=FCngliche Nachricht----- Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] = Gesendet: Dienstag, 19. Februar 2008 15:03 An: Freudenberger, Markus Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org Betreff: Re: [ANCP] missing items in the ancp-mib draft Hi Markus, Indeed, ANCP is just one application that uses IP, and as soon the ANCP pac= ket is encapsulated into an IP packet, it goes to the IP layer where it is = treated like any other IP packet. Suppose in ancpAnSessionConfigTable, an attribute VLAN is added, and I conf= igure this VLAN equal to 100. Ok, the AN can sent then the ANCP packet to = VLAN 100 (even though the IP routing table says that the best path to the N= AS IP address is via another VLAN), then my question is: = what will be the MAC destination address of this IP packet, i.e., to which = IP address has the AN to send an ARP request to learn the MAC destination a= ddress to be used for the ANCP packet? Knowing the VLAN ID is just not suf= ficient according to me. Either the NAS IP address MUST be in the subnet a= s the configured VLAN (in which case the ARP is directly to the NAS IP addr= ess), or an IP lookup is done that results in a next-hop with corresponding= outgoing interface (=3DVLAN, PVC, ...). In the latter case, no VLAN is ne= eded in ancpAnSessionConfigTable because the IP lookup will automatically g= ive the VLAN. For me both options are Ok, I just want to know how it has to work. regards, Stefaan Freudenberger, Markus wrote: > Moti, Stefaan, > = > I agree with Moti's comments. = > See my further comments to Stefaans statemtens inline, marked with "[MF]". > = > Are there views from other people? > = > regards > Markus > = > -----Urspr=FCngliche Nachricht----- > Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] > Gesendet: Montag, 18. Februar 2008 09:57 > An: Moti Morgenstern; Freudenberger, Markus > Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org > Betreff: Re: [ANCP] missing items in the ancp-mib draft > = > = > Moti, Markus, > = > Moti Morgenstern wrote: > = > = >>Hi, >> >>I think what Markus wrote is pretty correct. There should be, for example= , a MIB for associating ANCP session with "ANCP VLAN". So, if that MIB is a= lready available, in already existing RFCs, then the ANCP MIB should includ= e a section describing that as part of the "Relationship to Other MIB Modul= es", as done with the interfaces MIB. That will allow software engineers (e= ven if not members in our honorable ANCP WG) to see the whole picture. Howe= ver, if such a MIB is not available, then obviously the ANCP MIB should des= cribe what is the gap and define the MIB for filling it. = >> >>More specifically (and please correct me if I'm wrong): >>- I do not recall a MIB for ATM PVCs that assumes single VC with multiple= xed services. However, in this case I think that we do not need such a MIB = because the ANCP control channel should actually be associated with bridge = port (and that bridge port has a MIB that provides the information on the u= nderlying L2). The question is how does the EMS associate the ANCP control = channel with a specific bridge port? > = > = > An informational text can be added to explain how IP/ANCP packets are to = be routed but there is no formal linking with any other MIB. How the IP la= yer is configured is independent from how the protocol is configured. > = > [MF] > Stefaan, do you mean it is independent because ANCP is one of many other = applications which uses IP? If yes, you are right but the IP layer is essen= tial for ANCP (as the architecture chooses TCP/IP as a tranpsort medium) an= d as a consequence it is also essential to configure it and associate it wi= th a certain ANCP session from an EMS. This has to be mentioned somehow in = the document. I don't see a problem to create a reference to an RFC and/or = a MIB which provides these capabilities. But it is still needed to define = the link between the IP layer and ANCP session. > [MF] > = > = > For me it is also fine that ANCP packets are not routed in the AN but tha= t ANCP is bound to a certain interface (=3DVLAN or PVC) like it is for inst= ance with OSPF. But then the configured NAS IP address in the AN must be a= directly attached IP address, if the NAS IP address is not directly attach= ed, then the AN does not know which IP address to ARP (which it normally ge= ts from the next-hop of the matching route). > = > When ANCP bypasses routing, VLAN-ID or PVC (with some extra attributes on= ly specific for ANCP packets like for instance p-bits) could be configured = in ancpAnSessionConfigTable. > = > For me both options are fine, but if the second option is selected, the t= he framework draft should also mention this limitation (which should not be= a problem if we all agree I suspect). > = > [MF] > Sorry but I cannot indicate the options. Which limitation do you mean? = > Anyway, I think the ANCP packets are not routed in the AN, they are termi= nated and the next IP hop is the NAS. The ancp framework document states fo= r this purpose: > ... > o Control Channel: a bidirectional IP communication interface > between the controller function (in the NAS) and the reporting/ > enforcement function (in the AN). It is assumed that this > interface is configured (rather than discovered) on the AN and the > NAS. > ... > and > ... > o The Control Channel MUST be terminated at the Access Node. > ... > = > To summarize, I only see the option to add additional attributes into the= ancpAnSessionConfigTable for layer 2 connection parameters (VLAN, VCC, QoS= class, priority) per session. = > [MF] > = > What is your preference? > = > = > = >>- Stefaan says that "ANCP are IP packets originated from an IP address in= the AN" and that's correct. But how does the EMS configure that address? H= ow does the EMS associate it with one of possibly multiple sessions? >> > = > = > It is the IP routing table that associates an ANCP packet (IP packet) to = a certain outgoing interface. The AN IP address is not configured per sess= ion but you can see the selected IP address in ancpAnCurrentSessionTable. = Typically, when a device generates an IP packet, its IP source address is u= sually set to the IP address of the outgoing IP interface. When the AN onl= y has 1 IP address (after all it is not a router), then it is straitforward. > = > [MF] > I disagree, the AN has more than 1 IP address (e. g. for telnet/SNMP), so= we have to differentiate here and if one can see the IP addess for a sessi= on in the ancpAnCurrentSessionTable, someone has to configure it somewhere,= right? = > [MF] > = > regards, > Stefaan > = > = > = >>I'll be glad to hear more opinions on those issues. >> >>Regards, >>Moti >> >> >>-----Original Message----- >>From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = >>Of Stefaan DE CNODDER >>Sent: Friday, February 15, 2008 11:45 AM >>To: Freudenberger, Markus >>Cc: Haag, T; Busser,M; ancp@ietf.org >>Subject: Re: [ANCP] missing items in the ancp-mib draft >> >> >>Hi Markus, >> >>The parameters related to control channel has been intentionally not = >>been included in the ANCP MIB because these attributes are to be = >>configured in other MIBs. For instance, if the VLAN on which ANCP is = >>running needs p-bit 5, then that is to be configured in the = >>corresponding ethernet MIB where VLANs are configured. The same for >>PVCs: I guess there are ATM MIBs where the attributes of all the PVCs = >>can be configured. >> >>Then you also need the selection of the VLAN or PVC to be used for ANCP. = >> Actually, ANCP are IP packets originated from an IP address in the = >>AN, and transmitted like any other IP packet, i.e., the AN performs an = >>IP lookup in its routing table. So if the correct routing cannot be = >>achieved because the IP address of the directly attached interface of = >>the "ANCP VLAN" is not used as NAS address, then an appriopriate route = >>has to be configured such that these packets are going to the VLAN on = >>which they should be. However, also this "routing information" (in = >>whatever form) is to be configured in other MIBs than the ANCP MIB. >> >>Look it like this in case of ethernet: if the AN generates an ANCP = >>message to the NAS, then the ANCP message is put in an ethernet frame, = >>this ethernet frame needs a MAC destination address. To get the MAC = >>destination address, the AN has to send an ARP to an IP address. This = >>IP address is the next-hop IP address, which it gets from the routing = >>information. It can be a next-hop of a route, or in case the NAS IP = >>address is directly attached, the IP packet matches the direct route. >> >>So I have the feeling that this "routing information" for ANCP can = >>exist in multiple forms: >>(1) a route with next-hop, or directly attached >>(2) a VLAN (so no next-hop and then the NAS IP must be directly = >>attached for sending an ARP). >>- ... >> >>So I have the feeling that this just do not belong to an ANCP MIB. = >>For sure option (1) should not be in the ANCP MIB, (2) could be added = >>but since a generic solution anyhow requires (1), I do not see the = >>need to add something in the ANCP MIB. >> >>Extra filters in the ANCP MIB could be added like for instance that = >>ANCP messages may only be sent or received on particular VLANs, but = >>that is just an extra ACL, and each implementation can add as much = >>security as needed and this should maybe not be in a standard ANCP MIB. >> >>Do you agree with this? >> >>Thanks for the review, all comments are very welcome. >> >>regards, >>Stefaan >> >> >>Freudenberger, Markus wrote: >> >> >>>Hi all, >>> >>>looking into the actual ancp-mib draft, I am misssing the following: >>> >>>1) the possibilty to configure the IP address on the AN for the control = channel as it is already defined for the peer NAS. This implies adding addi= tional entries into the ancpAnCurrentSessionTable for reading the control c= hannel ip address of the NAS. >>> >>>2) the possibility to configure the allocation of control channel(s) to = a physical interface with VPI/VCI resp. C-/S-VAN-ID values and Qos/CoS sett= ing. = >>> >>>Both is required to allow the EMS the setup of the control channel with = SNMP and this is described in Section 6 of the ancp framework document anyw= ay (See below). = >>> >>>----------------------- snip from draft-ietf-ancp-framework-04.txt >>>----------------------- 6. Management Related Requirements >>> >>> o It must be possible to configure the following parameters on the >>> Access Node and the NAS: >>> >>> * Parameters related to the Control Channel transport method: >>> these include the VPI/VCI and transport characteristics (e.g. >>> VBR-rt or CBR) for ATM networks or the C-VLAN ID and S-VLAN ID >>> and p-bit marking for Ethernet networks; >>> >>> * Parameters related to the Control Channel itself: these include >>> the IP address of the IP interface on the Access Node and the >>> NAS >>>----------------------- snip from draft-ietf-ancp-framework-04.txt >>>----------------------- >>> >>>Any comments? >>> >>>Regards >>>Markus Freudenberger >>> >>>T-Systems Enterprise Services GmbH >>>Systems Integration >>>Telco Project & Design >>>Line of Business Networks & Processes Technology Consultant = >>>Deutsche-Telekom-Allee 7, D-64295 Darmstadt >>>+49 6151 937-3679 (Phone) >>>+49 6151 937-19875 (Fax) >>>+49 521 5224 5816 (PC-Fax) >>>E-Mail: mailto:markus.freudenberger@t-systems.com >>>Internet: http://t-systems.com >>> >>> >>> >>> >>>>T-Systems Enterprise Services GmbH >>>>Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: = >>>>Reinhard Clemens (Vorsitzender)*, Helmut Binder, Albert Henn, Olaf = >>>>Heyden*, Katrin Horstmann, Wilfried Peters*, Dr. Herbert Schaaff*, = >>>>Zvezdana Seeger* >>>>Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der >>>>Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 = >>>>*Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG >>>> >>> >>>Notice: This transmittal and/or attachments may be privileged or confide= ntial. If you are not the intended recipient, you are hereby notified that = you have received this transmittal in error; any review, dissemination, or = copying is strictly prohibited. If you received this transmittal in error, = please notify us immediately by reply and immediately delete this message a= nd all its attachments. Thank you. >>>T-Systems - Business flexibility >>> >>> >>>_______________________________________________ >>>ANCP mailing list >>>ANCP@ietf.org >>>http://www.ietf.org/mailman/listinfo/ancp >> >>_______________________________________________ >>ANCP mailing list >>ANCP@ietf.org >>http://www.ietf.org/mailman/listinfo/ancp > = > = _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Feb 19 07:38:42 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDC383A6E39; Tue, 19 Feb 2008 07:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.457 X-Spam-Level: X-Spam-Status: No, score=0.457 tagged_above=-999 required=5 tests=[AWL=-0.852, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRwQn-kmQUYc; Tue, 19 Feb 2008 07:38:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CF113A6E09; Tue, 19 Feb 2008 07:38:40 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D68A83A6E49 for ; Tue, 19 Feb 2008 07:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKWBjUQ79wkj for ; Tue, 19 Feb 2008 07:38:36 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id D0C423A6E2C for ; Tue, 19 Feb 2008 07:38:34 -0800 (PST) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m1JFQIkW023966; Tue, 19 Feb 2008 16:26:20 +0100 Received: from [172.31.131.165] ([172.31.131.165]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Tue, 19 Feb 2008 16:38:27 +0100 Message-ID: <47BAF7F4.3090503@alcatel-lucent.be> Date: Tue, 19 Feb 2008 16:38:28 +0100 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: "Freudenberger, Markus" References: <1B6169C658325341A3B8066E23919E1C81F76F@S4DE8PSAANK.mitte.t-com.de><47B55F0E.7040205@alcatel-lucent.be><83153A1EB675AF4F82E134FA27F95F6702F354FA@ilptex01.ecitele.com><47B94869.8030905@alcatel-lucent.be><1B6169C658325341A3B8066E23919E1C81F782@S4DE8PSAANK.mitte.t-com.de> <47BAE191.5040406@alcatel-lucent.be> <1B6169C658325341A3B8066E23919E1C81F785@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1B6169C658325341A3B8066E23919E1C81F785@S4DE8PSAANK.mitte.t-com.de> X-OriginalArrivalTime: 19 Feb 2008 15:38:27.0510 (UTC) FILETIME=[7898AD60:01C8730D] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "Haag, T" , "Busser, M" , ancp@ietf.org Subject: Re: [ANCP] missing items in the ancp-mib draft X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi Markus, In that case, the extra attributes are fine for me. Thanks, Stefaan Freudenberger, Markus wrote: > Hi Stefaan, > = > the ancp session runs in the subnet as the configured VLAN. > = > Example configuration: = > = > AN NAS > ----------------------------------- > Bridge-port 1 1 > S-VLAN-ID 10 10 > C-VLAN-ID 10 10 > prio 7 7 > VPI 32 32 = > VCI 32 32 > QoS CBR CBR > IP-address 192.168.0.1/30 192.168.0.2/30 > ... > = > regards > Markus = > = > = > -----Urspr=FCngliche Nachricht----- > Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] = > Gesendet: Dienstag, 19. Februar 2008 15:03 > An: Freudenberger, Markus > Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org > Betreff: Re: [ANCP] missing items in the ancp-mib draft > = > = > Hi Markus, > = > Indeed, ANCP is just one application that uses IP, and as soon the ANCP p= acket is encapsulated into an IP packet, it goes to the IP layer where it i= s treated like any other IP packet. > = > Suppose in ancpAnSessionConfigTable, an attribute VLAN is added, and I co= nfigure this VLAN equal to 100. Ok, the AN can sent then the ANCP packet t= o VLAN 100 (even though the IP routing table says that the best path to the= NAS IP address is via another VLAN), then my question is: = > what will be the MAC destination address of this IP packet, i.e., to whic= h IP address has the AN to send an ARP request to learn the MAC destination= address to be used for the ANCP packet? Knowing the VLAN ID is just not s= ufficient according to me. Either the NAS IP address MUST be in the subnet= as the configured VLAN (in which case the ARP is directly to the NAS IP ad= dress), or an IP lookup is done that results in a next-hop with correspondi= ng outgoing interface (=3DVLAN, PVC, ...). In the latter case, no VLAN is = needed in ancpAnSessionConfigTable because the IP lookup will automatically= give the VLAN. > = > For me both options are Ok, I just want to know how it has to work. > = > regards, > Stefaan > = > = > Freudenberger, Markus wrote: > = > = >>Moti, Stefaan, >> >>I agree with Moti's comments. = >>See my further comments to Stefaans statemtens inline, marked with "[MF]". >> >>Are there views from other people? >> >>regards >>Markus >> >>-----Urspr=FCngliche Nachricht----- >>Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] >>Gesendet: Montag, 18. Februar 2008 09:57 >>An: Moti Morgenstern; Freudenberger, Markus >>Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org >>Betreff: Re: [ANCP] missing items in the ancp-mib draft >> >> >>Moti, Markus, >> >>Moti Morgenstern wrote: >> >> >> >>>Hi, >>> >>>I think what Markus wrote is pretty correct. There should be, for exampl= e, a MIB for associating ANCP session with "ANCP VLAN". So, if that MIB is = already available, in already existing RFCs, then the ANCP MIB should inclu= de a section describing that as part of the "Relationship to Other MIB Modu= les", as done with the interfaces MIB. That will allow software engineers (= even if not members in our honorable ANCP WG) to see the whole picture. How= ever, if such a MIB is not available, then obviously the ANCP MIB should de= scribe what is the gap and define the MIB for filling it. = >>> >>>More specifically (and please correct me if I'm wrong): >>>- I do not recall a MIB for ATM PVCs that assumes single VC with multipl= exed services. However, in this case I think that we do not need such a MIB= because the ANCP control channel should actually be associated with bridge= port (and that bridge port has a MIB that provides the information on the = underlying L2). The question is how does the EMS associate the ANCP control= channel with a specific bridge port? >> >> >>An informational text can be added to explain how IP/ANCP packets are to = be routed but there is no formal linking with any other MIB. How the IP la= yer is configured is independent from how the protocol is configured. >> >>[MF] >>Stefaan, do you mean it is independent because ANCP is one of many other = applications which uses IP? If yes, you are right but the IP layer is essen= tial for ANCP (as the architecture chooses TCP/IP as a tranpsort medium) an= d as a consequence it is also essential to configure it and associate it wi= th a certain ANCP session from an EMS. This has to be mentioned somehow in = the document. I don't see a problem to create a reference to an RFC and/or = a MIB which provides these capabilities. But it is still needed to define = the link between the IP layer and ANCP session. >>[MF] >> >> >>For me it is also fine that ANCP packets are not routed in the AN but tha= t ANCP is bound to a certain interface (=3DVLAN or PVC) like it is for inst= ance with OSPF. But then the configured NAS IP address in the AN must be a= directly attached IP address, if the NAS IP address is not directly attach= ed, then the AN does not know which IP address to ARP (which it normally ge= ts from the next-hop of the matching route). >> >>When ANCP bypasses routing, VLAN-ID or PVC (with some extra attributes on= ly specific for ANCP packets like for instance p-bits) could be configured = in ancpAnSessionConfigTable. >> >>For me both options are fine, but if the second option is selected, the t= he framework draft should also mention this limitation (which should not be= a problem if we all agree I suspect). >> >>[MF] >>Sorry but I cannot indicate the options. Which limitation do you mean? = >>Anyway, I think the ANCP packets are not routed in the AN, they are termi= nated and the next IP hop is the NAS. The ancp framework document states fo= r this purpose: >>... >> o Control Channel: a bidirectional IP communication interface >> between the controller function (in the NAS) and the reporting/ >> enforcement function (in the AN). It is assumed that this >> interface is configured (rather than discovered) on the AN and the >> NAS. >>... >>and >>... >> o The Control Channel MUST be terminated at the Access Node. >>... >> >>To summarize, I only see the option to add additional attributes into the= ancpAnSessionConfigTable for layer 2 connection parameters (VLAN, VCC, QoS= class, priority) per session. = >>[MF] >> >>What is your preference? >> >> >> >> >>>- Stefaan says that "ANCP are IP packets originated from an IP address i= n the AN" and that's correct. But how does the EMS configure that address? = How does the EMS associate it with one of possibly multiple sessions? >>> >> >> >>It is the IP routing table that associates an ANCP packet (IP packet) to = a certain outgoing interface. The AN IP address is not configured per sess= ion but you can see the selected IP address in ancpAnCurrentSessionTable. = Typically, when a device generates an IP packet, its IP source address is u= sually set to the IP address of the outgoing IP interface. When the AN onl= y has 1 IP address (after all it is not a router), then it is straitforward. >> >>[MF] >>I disagree, the AN has more than 1 IP address (e. g. for telnet/SNMP), so= we have to differentiate here and if one can see the IP addess for a sessi= on in the ancpAnCurrentSessionTable, someone has to configure it somewhere,= right? = >>[MF] >> >>regards, >>Stefaan >> >> >> >> >>>I'll be glad to hear more opinions on those issues. >>> >>>Regards, >>>Moti >>> >>> >>>-----Original Message----- >>>From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = >>>Of Stefaan DE CNODDER >>>Sent: Friday, February 15, 2008 11:45 AM >>>To: Freudenberger, Markus >>>Cc: Haag, T; Busser,M; ancp@ietf.org >>>Subject: Re: [ANCP] missing items in the ancp-mib draft >>> >>> >>>Hi Markus, >>> >>>The parameters related to control channel has been intentionally not = >>>been included in the ANCP MIB because these attributes are to be = >>>configured in other MIBs. For instance, if the VLAN on which ANCP is = >>>running needs p-bit 5, then that is to be configured in the = >>>corresponding ethernet MIB where VLANs are configured. The same for >>>PVCs: I guess there are ATM MIBs where the attributes of all the PVCs = >>>can be configured. >>> >>>Then you also need the selection of the VLAN or PVC to be used for ANCP. = >>> Actually, ANCP are IP packets originated from an IP address in the = >>>AN, and transmitted like any other IP packet, i.e., the AN performs an = >>>IP lookup in its routing table. So if the correct routing cannot be = >>>achieved because the IP address of the directly attached interface of = >>>the "ANCP VLAN" is not used as NAS address, then an appriopriate route = >>>has to be configured such that these packets are going to the VLAN on = >>>which they should be. However, also this "routing information" (in = >>>whatever form) is to be configured in other MIBs than the ANCP MIB. >>> >>>Look it like this in case of ethernet: if the AN generates an ANCP = >>>message to the NAS, then the ANCP message is put in an ethernet frame, = >>>this ethernet frame needs a MAC destination address. To get the MAC = >>>destination address, the AN has to send an ARP to an IP address. This = >>>IP address is the next-hop IP address, which it gets from the routing = >>>information. It can be a next-hop of a route, or in case the NAS IP = >>>address is directly attached, the IP packet matches the direct route. >>> >>>So I have the feeling that this "routing information" for ANCP can = >>>exist in multiple forms: >>>(1) a route with next-hop, or directly attached >>>(2) a VLAN (so no next-hop and then the NAS IP must be directly = >>>attached for sending an ARP). >>>- ... >>> >>>So I have the feeling that this just do not belong to an ANCP MIB. = >>>For sure option (1) should not be in the ANCP MIB, (2) could be added = >>>but since a generic solution anyhow requires (1), I do not see the = >>>need to add something in the ANCP MIB. >>> >>>Extra filters in the ANCP MIB could be added like for instance that = >>>ANCP messages may only be sent or received on particular VLANs, but = >>>that is just an extra ACL, and each implementation can add as much = >>>security as needed and this should maybe not be in a standard ANCP MIB. >>> >>>Do you agree with this? >>> >>>Thanks for the review, all comments are very welcome. >>> >>>regards, >>>Stefaan >>> >>> >>>Freudenberger, Markus wrote: >>> >>> >>> >>>>Hi all, >>>> >>>>looking into the actual ancp-mib draft, I am misssing the following: >>>> >>>>1) the possibilty to configure the IP address on the AN for the control= channel as it is already defined for the peer NAS. This implies adding add= itional entries into the ancpAnCurrentSessionTable for reading the control = channel ip address of the NAS. >>>> >>>>2) the possibility to configure the allocation of control channel(s) to= a physical interface with VPI/VCI resp. C-/S-VAN-ID values and Qos/CoS set= ting. = >>>> >>>>Both is required to allow the EMS the setup of the control channel with= SNMP and this is described in Section 6 of the ancp framework document any= way (See below). = >>>> >>>>----------------------- snip from draft-ietf-ancp-framework-04.txt >>>>----------------------- 6. Management Related Requirements >>>> >>>> o It must be possible to configure the following parameters on the >>>> Access Node and the NAS: >>>> >>>> * Parameters related to the Control Channel transport method: >>>> these include the VPI/VCI and transport characteristics (e.g. >>>> VBR-rt or CBR) for ATM networks or the C-VLAN ID and S-VLAN ID >>>> and p-bit marking for Ethernet networks; >>>> >>>> * Parameters related to the Control Channel itself: these include >>>> the IP address of the IP interface on the Access Node and the >>>> NAS >>>>----------------------- snip from draft-ietf-ancp-framework-04.txt >>>>----------------------- >>>> >>>>Any comments? >>>> >>>>Regards >>>>Markus Freudenberger >>>> >>>>T-Systems Enterprise Services GmbH >>>>Systems Integration >>>>Telco Project & Design >>>>Line of Business Networks & Processes Technology Consultant = >>>>Deutsche-Telekom-Allee 7, D-64295 Darmstadt >>>>+49 6151 937-3679 (Phone) >>>>+49 6151 937-19875 (Fax) >>>>+49 521 5224 5816 (PC-Fax) >>>>E-Mail: mailto:markus.freudenberger@t-systems.com >>>>Internet: http://t-systems.com >>>> >>>> >>>> >>>> >>>> >>>>>T-Systems Enterprise Services GmbH >>>>>Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: = >>>>>Reinhard Clemens (Vorsitzender)*, Helmut Binder, Albert Henn, Olaf = >>>>>Heyden*, Katrin Horstmann, Wilfried Peters*, Dr. Herbert Schaaff*, = >>>>>Zvezdana Seeger* >>>>>Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der >>>>>Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 = >>>>>*Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG >>>>> >>>> >>>>Notice: This transmittal and/or attachments may be privileged or confid= ential. If you are not the intended recipient, you are hereby notified that= you have received this transmittal in error; any review, dissemination, or= copying is strictly prohibited. If you received this transmittal in error,= please notify us immediately by reply and immediately delete this message = and all its attachments. Thank you. >>>>T-Systems - Business flexibility >>>> >>>> >>>>_______________________________________________ >>>>ANCP mailing list >>>>ANCP@ietf.org >>>>http://www.ietf.org/mailman/listinfo/ancp >>> >>>_______________________________________________ >>>ANCP mailing list >>>ANCP@ietf.org >>>http://www.ietf.org/mailman/listinfo/ancp >> >> > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > http://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Feb 19 14:08:12 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F33A28C69D; Tue, 19 Feb 2008 14:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=-3.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwM+USnNMlRM; Tue, 19 Feb 2008 14:08:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 952EF28C69E; Tue, 19 Feb 2008 14:08:11 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A806A28C5F9 for ; Tue, 19 Feb 2008 14:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBSgECuteR69 for ; Tue, 19 Feb 2008 14:08:08 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id C59E328C69D for ; Tue, 19 Feb 2008 14:08:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,378,1199692800"; d="scan'208,217";a="6311033" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 19 Feb 2008 14:08:06 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1JM86eG024390 for ; Tue, 19 Feb 2008 14:08:06 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1JM7mwD019935 for ; Tue, 19 Feb 2008 22:08:05 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 14:07:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 14:08:11 -0800 Message-ID: <48214755113BB04F84D958B4F0DE261C05315427@xmb-sjc-222.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Agenda items for IETF71 ANCP WG meeting Thread-Index: AchUUQtbSvlJlJPeRGysqgny0e3nCQd7TxMgAEEsvxA= References: From: "Philippe Champagne (pchamp)" To: "Wojciech Dec (wdec)" , X-OriginalArrivalTime: 19 Feb 2008 22:07:59.0586 (UTC) FILETIME=[E3707420:01C87343] Authentication-Results: sj-dkim-1; header.From=pchamp@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [ANCP] Agenda items for IETF71 ANCP WG meeting X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 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="===============1314804665==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1314804665== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87343.E20F9D10" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87343.E20F9D10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Woj The design team should have something ready by then to present. It will likely only include the protocol basic structures and packet format definition with probably a few flow example. =20 =20 =20 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Monday, February 18, 2008 10:09 AM To: ancp@ietf.org Subject: Re: [ANCP] Agenda items for IETF71 ANCP WG meeting =09 =09 Hi All, =20 are there any other calls for slots at the upcoming meeting? =20 So far we have the following: - ANCP Access-node & NAS MIB Update; Stefaan De Cnodder - ANCP Design Team update (tentative) =20 Regards, Woj. ________________________________ From: Wojciech Dec (wdec)=20 Sent: 11 January 2008 14:04 To: ancp@ietf.org Subject: [ANCP] Agenda items for IETF71 ANCP WG meeting=20 =09 =09 We're taking requests for slots in the agenda for our next ANCP WG meeting. Please respond with any tentative requests by February 8. Thanks,=20 Matthew & Woj=20 ------_=_NextPart_001_01C87343.E20F9D10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda items for IETF71 ANCP WG meeting
 
Woj

The design team should have something ready by then to present. = It will=20 likely only include the protocol basic=20 structures and packet format = definition=20 with probably a few flow = example.
 
 
 

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec=20 (wdec)
Sent: Monday, February 18, 2008 10:09 = AM
To:=20 ancp@ietf.org
Subject: Re: [ANCP] Agenda items for IETF71 = ANCP WG=20 meeting

Hi All,
 
are there any other calls for slots at the = upcoming=20 meeting?
 
So far we have the = following:
- ANCP Access-node & NAS MIB Update; = Stefaan De=20 Cnodder
- ANCP Design Team update=20 (tentative)
 
Regards,
Woj.

From: Wojciech Dec (wdec) =
Sent:=20 11 January 2008 14:04
To: ancp@ietf.org
Subject: = [ANCP]=20 Agenda items for IETF71 ANCP WG meeting

We're taking requests for = slots in the=20 agenda for our next ANCP WG meeting.  Please respond with any = tentative=20 requests by February 8.

Thanks,
Matthew & Woj=20

------_=_NextPart_001_01C87343.E20F9D10-- --===============1314804665== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp --===============1314804665==-- From ancp-bounces@ietf.org Wed Feb 20 05:25:38 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4868428C80C; Wed, 20 Feb 2008 05:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.548 X-Spam-Level: X-Spam-Status: No, score=0.548 tagged_above=-999 required=5 tests=[AWL=-0.761, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHkJRyR94jTb; Wed, 20 Feb 2008 05:25:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9BAA28C7C0; Wed, 20 Feb 2008 05:25:33 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FD0828C7F7 for ; Wed, 20 Feb 2008 05:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxlRRqq7Yv9h for ; Wed, 20 Feb 2008 05:25:31 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id F3F1C28C7C0 for ; Wed, 20 Feb 2008 05:25:30 -0800 (PST) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m1KDD6RW011774; Wed, 20 Feb 2008 14:13:06 +0100 Received: from [172.31.131.165] ([172.31.131.165]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Wed, 20 Feb 2008 14:25:25 +0100 Message-ID: <47BC2A44.4050104@alcatel-lucent.be> Date: Wed, 20 Feb 2008 14:25:24 +0100 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: "Freudenberger, Markus" References: <1B6169C658325341A3B8066E23919E1C81F76F@S4DE8PSAANK.mitte.t-com.de><47B55F0E.7040205@alcatel-lucent.be><83153A1EB675AF4F82E134FA27F95F6702F354FA@ilptex01.ecitele.com><47B94869.8030905@alcatel-lucent.be><1B6169C658325341A3B8066E23919E1C81F782@S4DE8PSAANK.mitte.t-com.de> <47BAE191.5040406@alcatel-lucent.be> <1B6169C658325341A3B8066E23919E1C81F785@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1B6169C658325341A3B8066E23919E1C81F785@S4DE8PSAANK.mitte.t-com.de> X-OriginalArrivalTime: 20 Feb 2008 13:25:25.0359 (UTC) FILETIME=[0D46D7F0:01C873C4] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "Haag, T" , "Busser, M" , ancp@ietf.org Subject: Re: [ANCP] missing items in the ancp-mib draft X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Markus, Thinking further about this: S/C VLAN, p-bit, VPI/VCI can be added to = the cofiguration per session, but not the QoS class for VPI/VCI. = Because if a PVC is used for 10 ANCP sessions, then it cannot be that = one session uses this PVC as UBR and another session as CBR. Also CBR = requires extra parameters like a bandwidth, and VBR even requires more = like leaky bucket sizes, ... This all looks very specific ATM = configuration not to be part of the ANCP MIB. So it is Ok for you to add the following objects to the configuration of = a session: S-VLAN C-VLAN p-bits VPI VCI Without QoS regards, Stefaan Freudenberger, Markus wrote: > Hi Stefaan, > = > the ancp session runs in the subnet as the configured VLAN. > = > Example configuration: = > = > AN NAS > ----------------------------------- > Bridge-port 1 1 > S-VLAN-ID 10 10 > C-VLAN-ID 10 10 > prio 7 7 > VPI 32 32 = > VCI 32 32 > QoS CBR CBR > IP-address 192.168.0.1/30 192.168.0.2/30 > ... > = > regards > Markus = > = > = > -----Urspr=FCngliche Nachricht----- > Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] = > Gesendet: Dienstag, 19. Februar 2008 15:03 > An: Freudenberger, Markus > Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org > Betreff: Re: [ANCP] missing items in the ancp-mib draft > = > = > Hi Markus, > = > Indeed, ANCP is just one application that uses IP, and as soon the ANCP p= acket is encapsulated into an IP packet, it goes to the IP layer where it i= s treated like any other IP packet. > = > Suppose in ancpAnSessionConfigTable, an attribute VLAN is added, and I co= nfigure this VLAN equal to 100. Ok, the AN can sent then the ANCP packet t= o VLAN 100 (even though the IP routing table says that the best path to the= NAS IP address is via another VLAN), then my question is: = > what will be the MAC destination address of this IP packet, i.e., to whic= h IP address has the AN to send an ARP request to learn the MAC destination= address to be used for the ANCP packet? Knowing the VLAN ID is just not s= ufficient according to me. Either the NAS IP address MUST be in the subnet= as the configured VLAN (in which case the ARP is directly to the NAS IP ad= dress), or an IP lookup is done that results in a next-hop with correspondi= ng outgoing interface (=3DVLAN, PVC, ...). In the latter case, no VLAN is = needed in ancpAnSessionConfigTable because the IP lookup will automatically= give the VLAN. > = > For me both options are Ok, I just want to know how it has to work. > = > regards, > Stefaan > = > = > Freudenberger, Markus wrote: > = > = >>Moti, Stefaan, >> >>I agree with Moti's comments. = >>See my further comments to Stefaans statemtens inline, marked with "[MF]". >> >>Are there views from other people? >> >>regards >>Markus >> >>-----Urspr=FCngliche Nachricht----- >>Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] >>Gesendet: Montag, 18. Februar 2008 09:57 >>An: Moti Morgenstern; Freudenberger, Markus >>Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org >>Betreff: Re: [ANCP] missing items in the ancp-mib draft >> >> >>Moti, Markus, >> >>Moti Morgenstern wrote: >> >> >> >>>Hi, >>> >>>I think what Markus wrote is pretty correct. There should be, for exampl= e, a MIB for associating ANCP session with "ANCP VLAN". So, if that MIB is = already available, in already existing RFCs, then the ANCP MIB should inclu= de a section describing that as part of the "Relationship to Other MIB Modu= les", as done with the interfaces MIB. That will allow software engineers (= even if not members in our honorable ANCP WG) to see the whole picture. How= ever, if such a MIB is not available, then obviously the ANCP MIB should de= scribe what is the gap and define the MIB for filling it. = >>> >>>More specifically (and please correct me if I'm wrong): >>>- I do not recall a MIB for ATM PVCs that assumes single VC with multipl= exed services. However, in this case I think that we do not need such a MIB= because the ANCP control channel should actually be associated with bridge= port (and that bridge port has a MIB that provides the information on the = underlying L2). The question is how does the EMS associate the ANCP control= channel with a specific bridge port? >> >> >>An informational text can be added to explain how IP/ANCP packets are to = be routed but there is no formal linking with any other MIB. How the IP la= yer is configured is independent from how the protocol is configured. >> >>[MF] >>Stefaan, do you mean it is independent because ANCP is one of many other = applications which uses IP? If yes, you are right but the IP layer is essen= tial for ANCP (as the architecture chooses TCP/IP as a tranpsort medium) an= d as a consequence it is also essential to configure it and associate it wi= th a certain ANCP session from an EMS. This has to be mentioned somehow in = the document. I don't see a problem to create a reference to an RFC and/or = a MIB which provides these capabilities. But it is still needed to define = the link between the IP layer and ANCP session. >>[MF] >> >> >>For me it is also fine that ANCP packets are not routed in the AN but tha= t ANCP is bound to a certain interface (=3DVLAN or PVC) like it is for inst= ance with OSPF. But then the configured NAS IP address in the AN must be a= directly attached IP address, if the NAS IP address is not directly attach= ed, then the AN does not know which IP address to ARP (which it normally ge= ts from the next-hop of the matching route). >> >>When ANCP bypasses routing, VLAN-ID or PVC (with some extra attributes on= ly specific for ANCP packets like for instance p-bits) could be configured = in ancpAnSessionConfigTable. >> >>For me both options are fine, but if the second option is selected, the t= he framework draft should also mention this limitation (which should not be= a problem if we all agree I suspect). >> >>[MF] >>Sorry but I cannot indicate the options. Which limitation do you mean? = >>Anyway, I think the ANCP packets are not routed in the AN, they are termi= nated and the next IP hop is the NAS. The ancp framework document states fo= r this purpose: >>... >> o Control Channel: a bidirectional IP communication interface >> between the controller function (in the NAS) and the reporting/ >> enforcement function (in the AN). It is assumed that this >> interface is configured (rather than discovered) on the AN and the >> NAS. >>... >>and >>... >> o The Control Channel MUST be terminated at the Access Node. >>... >> >>To summarize, I only see the option to add additional attributes into the= ancpAnSessionConfigTable for layer 2 connection parameters (VLAN, VCC, QoS= class, priority) per session. = >>[MF] >> >>What is your preference? >> >> >> >> >>>- Stefaan says that "ANCP are IP packets originated from an IP address i= n the AN" and that's correct. But how does the EMS configure that address? = How does the EMS associate it with one of possibly multiple sessions? >>> >> >> >>It is the IP routing table that associates an ANCP packet (IP packet) to = a certain outgoing interface. The AN IP address is not configured per sess= ion but you can see the selected IP address in ancpAnCurrentSessionTable. = Typically, when a device generates an IP packet, its IP source address is u= sually set to the IP address of the outgoing IP interface. When the AN onl= y has 1 IP address (after all it is not a router), then it is straitforward. >> >>[MF] >>I disagree, the AN has more than 1 IP address (e. g. for telnet/SNMP), so= we have to differentiate here and if one can see the IP addess for a sessi= on in the ancpAnCurrentSessionTable, someone has to configure it somewhere,= right? = >>[MF] >> >>regards, >>Stefaan >> >> >> >> >>>I'll be glad to hear more opinions on those issues. >>> >>>Regards, >>>Moti >>> >>> >>>-----Original Message----- >>>From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = >>>Of Stefaan DE CNODDER >>>Sent: Friday, February 15, 2008 11:45 AM >>>To: Freudenberger, Markus >>>Cc: Haag, T; Busser,M; ancp@ietf.org >>>Subject: Re: [ANCP] missing items in the ancp-mib draft >>> >>> >>>Hi Markus, >>> >>>The parameters related to control channel has been intentionally not = >>>been included in the ANCP MIB because these attributes are to be = >>>configured in other MIBs. For instance, if the VLAN on which ANCP is = >>>running needs p-bit 5, then that is to be configured in the = >>>corresponding ethernet MIB where VLANs are configured. The same for >>>PVCs: I guess there are ATM MIBs where the attributes of all the PVCs = >>>can be configured. >>> >>>Then you also need the selection of the VLAN or PVC to be used for ANCP. = >>> Actually, ANCP are IP packets originated from an IP address in the = >>>AN, and transmitted like any other IP packet, i.e., the AN performs an = >>>IP lookup in its routing table. So if the correct routing cannot be = >>>achieved because the IP address of the directly attached interface of = >>>the "ANCP VLAN" is not used as NAS address, then an appriopriate route = >>>has to be configured such that these packets are going to the VLAN on = >>>which they should be. However, also this "routing information" (in = >>>whatever form) is to be configured in other MIBs than the ANCP MIB. >>> >>>Look it like this in case of ethernet: if the AN generates an ANCP = >>>message to the NAS, then the ANCP message is put in an ethernet frame, = >>>this ethernet frame needs a MAC destination address. To get the MAC = >>>destination address, the AN has to send an ARP to an IP address. This = >>>IP address is the next-hop IP address, which it gets from the routing = >>>information. It can be a next-hop of a route, or in case the NAS IP = >>>address is directly attached, the IP packet matches the direct route. >>> >>>So I have the feeling that this "routing information" for ANCP can = >>>exist in multiple forms: >>>(1) a route with next-hop, or directly attached >>>(2) a VLAN (so no next-hop and then the NAS IP must be directly = >>>attached for sending an ARP). >>>- ... >>> >>>So I have the feeling that this just do not belong to an ANCP MIB. = >>>For sure option (1) should not be in the ANCP MIB, (2) could be added = >>>but since a generic solution anyhow requires (1), I do not see the = >>>need to add something in the ANCP MIB. >>> >>>Extra filters in the ANCP MIB could be added like for instance that = >>>ANCP messages may only be sent or received on particular VLANs, but = >>>that is just an extra ACL, and each implementation can add as much = >>>security as needed and this should maybe not be in a standard ANCP MIB. >>> >>>Do you agree with this? >>> >>>Thanks for the review, all comments are very welcome. >>> >>>regards, >>>Stefaan >>> >>> >>>Freudenberger, Markus wrote: >>> >>> >>> >>>>Hi all, >>>> >>>>looking into the actual ancp-mib draft, I am misssing the following: >>>> >>>>1) the possibilty to configure the IP address on the AN for the control= channel as it is already defined for the peer NAS. This implies adding add= itional entries into the ancpAnCurrentSessionTable for reading the control = channel ip address of the NAS. >>>> >>>>2) the possibility to configure the allocation of control channel(s) to= a physical interface with VPI/VCI resp. C-/S-VAN-ID values and Qos/CoS set= ting. = >>>> >>>>Both is required to allow the EMS the setup of the control channel with= SNMP and this is described in Section 6 of the ancp framework document any= way (See below). = >>>> >>>>----------------------- snip from draft-ietf-ancp-framework-04.txt >>>>----------------------- 6. Management Related Requirements >>>> >>>> o It must be possible to configure the following parameters on the >>>> Access Node and the NAS: >>>> >>>> * Parameters related to the Control Channel transport method: >>>> these include the VPI/VCI and transport characteristics (e.g. >>>> VBR-rt or CBR) for ATM networks or the C-VLAN ID and S-VLAN ID >>>> and p-bit marking for Ethernet networks; >>>> >>>> * Parameters related to the Control Channel itself: these include >>>> the IP address of the IP interface on the Access Node and the >>>> NAS >>>>----------------------- snip from draft-ietf-ancp-framework-04.txt >>>>----------------------- >>>> >>>>Any comments? >>>> >>>>Regards >>>>Markus Freudenberger >>>> >>>>T-Systems Enterprise Services GmbH >>>>Systems Integration >>>>Telco Project & Design >>>>Line of Business Networks & Processes Technology Consultant = >>>>Deutsche-Telekom-Allee 7, D-64295 Darmstadt >>>>+49 6151 937-3679 (Phone) >>>>+49 6151 937-19875 (Fax) >>>>+49 521 5224 5816 (PC-Fax) >>>>E-Mail: mailto:markus.freudenberger@t-systems.com >>>>Internet: http://t-systems.com >>>> >>>> >>>> >>>> >>>> >>>>>T-Systems Enterprise Services GmbH >>>>>Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: = >>>>>Reinhard Clemens (Vorsitzender)*, Helmut Binder, Albert Henn, Olaf = >>>>>Heyden*, Katrin Horstmann, Wilfried Peters*, Dr. Herbert Schaaff*, = >>>>>Zvezdana Seeger* >>>>>Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der >>>>>Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 = >>>>>*Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG >>>>> >>>> >>>>Notice: This transmittal and/or attachments may be privileged or confid= ential. If you are not the intended recipient, you are hereby notified that= you have received this transmittal in error; any review, dissemination, or= copying is strictly prohibited. If you received this transmittal in error,= please notify us immediately by reply and immediately delete this message = and all its attachments. Thank you. >>>>T-Systems - Business flexibility >>>> >>>> >>>>_______________________________________________ >>>>ANCP mailing list >>>>ANCP@ietf.org >>>>http://www.ietf.org/mailman/listinfo/ancp >>> >>>_______________________________________________ >>>ANCP mailing list >>>ANCP@ietf.org >>>http://www.ietf.org/mailman/listinfo/ancp >> >> > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > http://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Feb 20 07:05:07 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 344D428C79F; Wed, 20 Feb 2008 07:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.069 X-Spam-Level: X-Spam-Status: No, score=0.069 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grzY4M0-ZFGz; Wed, 20 Feb 2008 07:05:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C8C728C1CD; Wed, 20 Feb 2008 07:05:05 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7E3128C14A for ; Wed, 20 Feb 2008 07:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wyud61JE2XkW for ; Wed, 20 Feb 2008 07:05:02 -0800 (PST) Received: from eci-iron1.ecitele.com (eci-iron1.ecitele.com [147.234.242.117]) by core3.amsl.com (Postfix) with ESMTP id BEA0628C1CD for ; Wed, 20 Feb 2008 07:05:00 -0800 (PST) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 20 Feb 2008 17:33:02 +0200 Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Feb 2008 17:04:56 +0200 Received: from ILPTMAIL01.ecitele.com (147.234.245.210) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server id 8.1.240.5; Wed, 20 Feb 2008 17:04:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 17:04:52 +0200 Message-ID: <83153A1EB675AF4F82E134FA27F95F6702F9C8D0@ilptex01.ecitele.com> In-Reply-To: <47BC2A44.4050104@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] missing items in the ancp-mib draft Thread-Index: AchzxBilFbylKEI0ToOjIeujZ3bQPgADPzwg References: <1B6169C658325341A3B8066E23919E1C81F76F@S4DE8PSAANK.mitte.t-com.de><47B55F0E.7040205@alcatel-lucent.be><83153A1EB675AF4F82E134FA27F95F6702F354FA@ilptex01.ecitele.com><47B94869.8030905@alcatel-lucent.be><1B6169C658325341A3B8066E23919E1C81F782@S4DE8PSAANK.mitte.t-com.de><47BAE191.5040406@alcatel-lucent.be><1B6169C658325341A3B8066E23919E1C81F785@S4DE8PSAANK.mitte.t-com.de> <47BC2A44.4050104@alcatel-lucent.be> From: Moti Morgenstern To: "Stefaan DE CNODDER" , "Freudenberger, Markus" X-OriginalArrivalTime: 20 Feb 2008 15:04:56.0892 (UTC) FILETIME=[F49677C0:01C873D1] Cc: "Haag, T" , "Busser, M" , ancp@ietf.org Subject: Re: [ANCP] missing items in the ancp-mib draft X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi Markus & Stefaan, I think that it is more correct to associate the ANCP session with a bridge= port identifier. This is cleaner because then the IETF bridge MIB provides= the information regarding to the underlaying entity, which can perfectly b= e ATM PVC. Regards, Moti = -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Ste= faan DE CNODDER Sent: Wednesday, February 20, 2008 3:25 PM To: Freudenberger, Markus Cc: Haag, T; Busser,M; ancp@ietf.org Subject: Re: [ANCP] missing items in the ancp-mib draft Markus, Thinking further about this: S/C VLAN, p-bit, VPI/VCI can be added to = the cofiguration per session, but not the QoS class for VPI/VCI. = Because if a PVC is used for 10 ANCP sessions, then it cannot be that = one session uses this PVC as UBR and another session as CBR. Also CBR = requires extra parameters like a bandwidth, and VBR even requires more = like leaky bucket sizes, ... This all looks very specific ATM = configuration not to be part of the ANCP MIB. So it is Ok for you to add the following objects to the configuration of = a session: S-VLAN C-VLAN p-bits VPI VCI Without QoS regards, Stefaan Freudenberger, Markus wrote: > Hi Stefaan, > = > the ancp session runs in the subnet as the configured VLAN. > = > Example configuration: = > = > AN NAS > ----------------------------------- > Bridge-port 1 1 > S-VLAN-ID 10 10 > C-VLAN-ID 10 10 > prio 7 7 > VPI 32 32 = > VCI 32 32 > QoS CBR CBR > IP-address 192.168.0.1/30 192.168.0.2/30 > ... > = > regards > Markus = > = > = > -----Urspr=FCngliche Nachricht----- > Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] = > Gesendet: Dienstag, 19. Februar 2008 15:03 > An: Freudenberger, Markus > Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org > Betreff: Re: [ANCP] missing items in the ancp-mib draft > = > = > Hi Markus, > = > Indeed, ANCP is just one application that uses IP, and as soon the ANCP p= acket is encapsulated into an IP packet, it goes to the IP layer where it i= s treated like any other IP packet. > = > Suppose in ancpAnSessionConfigTable, an attribute VLAN is added, and I co= nfigure this VLAN equal to 100. Ok, the AN can sent then the ANCP packet t= o VLAN 100 (even though the IP routing table says that the best path to the= NAS IP address is via another VLAN), then my question is: = > what will be the MAC destination address of this IP packet, i.e., to whic= h IP address has the AN to send an ARP request to learn the MAC destination= address to be used for the ANCP packet? Knowing the VLAN ID is just not s= ufficient according to me. Either the NAS IP address MUST be in the subnet= as the configured VLAN (in which case the ARP is directly to the NAS IP ad= dress), or an IP lookup is done that results in a next-hop with correspondi= ng outgoing interface (=3DVLAN, PVC, ...). In the latter case, no VLAN is = needed in ancpAnSessionConfigTable because the IP lookup will automatically= give the VLAN. > = > For me both options are Ok, I just want to know how it has to work. > = > regards, > Stefaan > = > = > Freudenberger, Markus wrote: > = > = >>Moti, Stefaan, >> >>I agree with Moti's comments. = >>See my further comments to Stefaans statemtens inline, marked with "[MF]". >> >>Are there views from other people? >> >>regards >>Markus >> >>-----Urspr=FCngliche Nachricht----- >>Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] >>Gesendet: Montag, 18. Februar 2008 09:57 >>An: Moti Morgenstern; Freudenberger, Markus >>Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org >>Betreff: Re: [ANCP] missing items in the ancp-mib draft >> >> >>Moti, Markus, >> >>Moti Morgenstern wrote: >> >> >> >>>Hi, >>> >>>I think what Markus wrote is pretty correct. There should be, for exampl= e, a MIB for associating ANCP session with "ANCP VLAN". So, if that MIB is = already available, in already existing RFCs, then the ANCP MIB should inclu= de a section describing that as part of the "Relationship to Other MIB Modu= les", as done with the interfaces MIB. That will allow software engineers (= even if not members in our honorable ANCP WG) to see the whole picture. How= ever, if such a MIB is not available, then obviously the ANCP MIB should de= scribe what is the gap and define the MIB for filling it. = >>> >>>More specifically (and please correct me if I'm wrong): >>>- I do not recall a MIB for ATM PVCs that assumes single VC with multipl= exed services. However, in this case I think that we do not need such a MIB= because the ANCP control channel should actually be associated with bridge= port (and that bridge port has a MIB that provides the information on the = underlying L2). The question is how does the EMS associate the ANCP control= channel with a specific bridge port? >> >> >>An informational text can be added to explain how IP/ANCP packets are to = be routed but there is no formal linking with any other MIB. How the IP la= yer is configured is independent from how the protocol is configured. >> >>[MF] >>Stefaan, do you mean it is independent because ANCP is one of many other = applications which uses IP? If yes, you are right but the IP layer is essen= tial for ANCP (as the architecture chooses TCP/IP as a tranpsort medium) an= d as a consequence it is also essential to configure it and associate it wi= th a certain ANCP session from an EMS. This has to be mentioned somehow in = the document. I don't see a problem to create a reference to an RFC and/or = a MIB which provides these capabilities. But it is still needed to define = the link between the IP layer and ANCP session. >>[MF] >> >> >>For me it is also fine that ANCP packets are not routed in the AN but tha= t ANCP is bound to a certain interface (=3DVLAN or PVC) like it is for inst= ance with OSPF. But then the configured NAS IP address in the AN must be a= directly attached IP address, if the NAS IP address is not directly attach= ed, then the AN does not know which IP address to ARP (which it normally ge= ts from the next-hop of the matching route). >> >>When ANCP bypasses routing, VLAN-ID or PVC (with some extra attributes on= ly specific for ANCP packets like for instance p-bits) could be configured = in ancpAnSessionConfigTable. >> >>For me both options are fine, but if the second option is selected, the t= he framework draft should also mention this limitation (which should not be= a problem if we all agree I suspect). >> >>[MF] >>Sorry but I cannot indicate the options. Which limitation do you mean? = >>Anyway, I think the ANCP packets are not routed in the AN, they are termi= nated and the next IP hop is the NAS. The ancp framework document states fo= r this purpose: >>... >> o Control Channel: a bidirectional IP communication interface >> between the controller function (in the NAS) and the reporting/ >> enforcement function (in the AN). It is assumed that this >> interface is configured (rather than discovered) on the AN and the >> NAS. >>... >>and >>... >> o The Control Channel MUST be terminated at the Access Node. >>... >> >>To summarize, I only see the option to add additional attributes into the= ancpAnSessionConfigTable for layer 2 connection parameters (VLAN, VCC, QoS= class, priority) per session. = >>[MF] >> >>What is your preference? >> >> >> >> >>>- Stefaan says that "ANCP are IP packets originated from an IP address i= n the AN" and that's correct. But how does the EMS configure that address? = How does the EMS associate it with one of possibly multiple sessions? >>> >> >> >>It is the IP routing table that associates an ANCP packet (IP packet) to = a certain outgoing interface. The AN IP address is not configured per sess= ion but you can see the selected IP address in ancpAnCurrentSessionTable. = Typically, when a device generates an IP packet, its IP source address is u= sually set to the IP address of the outgoing IP interface. When the AN onl= y has 1 IP address (after all it is not a router), then it is straitforward. >> >>[MF] >>I disagree, the AN has more than 1 IP address (e. g. for telnet/SNMP), so= we have to differentiate here and if one can see the IP addess for a sessi= on in the ancpAnCurrentSessionTable, someone has to configure it somewhere,= right? = >>[MF] >> >>regards, >>Stefaan >> >> >> >> >>>I'll be glad to hear more opinions on those issues. >>> >>>Regards, >>>Moti >>> >>> >>>-----Original Message----- >>>From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = >>>Of Stefaan DE CNODDER >>>Sent: Friday, February 15, 2008 11:45 AM >>>To: Freudenberger, Markus >>>Cc: Haag, T; Busser,M; ancp@ietf.org >>>Subject: Re: [ANCP] missing items in the ancp-mib draft >>> >>> >>>Hi Markus, >>> >>>The parameters related to control channel has been intentionally not = >>>been included in the ANCP MIB because these attributes are to be = >>>configured in other MIBs. For instance, if the VLAN on which ANCP is = >>>running needs p-bit 5, then that is to be configured in the = >>>corresponding ethernet MIB where VLANs are configured. The same for >>>PVCs: I guess there are ATM MIBs where the attributes of all the PVCs = >>>can be configured. >>> >>>Then you also need the selection of the VLAN or PVC to be used for ANCP. = >>> Actually, ANCP are IP packets originated from an IP address in the = >>>AN, and transmitted like any other IP packet, i.e., the AN performs an = >>>IP lookup in its routing table. So if the correct routing cannot be = >>>achieved because the IP address of the directly attached interface of = >>>the "ANCP VLAN" is not used as NAS address, then an appriopriate route = >>>has to be configured such that these packets are going to the VLAN on = >>>which they should be. However, also this "routing information" (in = >>>whatever form) is to be configured in other MIBs than the ANCP MIB. >>> >>>Look it like this in case of ethernet: if the AN generates an ANCP = >>>message to the NAS, then the ANCP message is put in an ethernet frame, = >>>this ethernet frame needs a MAC destination address. To get the MAC = >>>destination address, the AN has to send an ARP to an IP address. This = >>>IP address is the next-hop IP address, which it gets from the routing = >>>information. It can be a next-hop of a route, or in case the NAS IP = >>>address is directly attached, the IP packet matches the direct route. >>> >>>So I have the feeling that this "routing information" for ANCP can = >>>exist in multiple forms: >>>(1) a route with next-hop, or directly attached >>>(2) a VLAN (so no next-hop and then the NAS IP must be directly = >>>attached for sending an ARP). >>>- ... >>> >>>So I have the feeling that this just do not belong to an ANCP MIB. = >>>For sure option (1) should not be in the ANCP MIB, (2) could be added = >>>but since a generic solution anyhow requires (1), I do not see the = >>>need to add something in the ANCP MIB. >>> >>>Extra filters in the ANCP MIB could be added like for instance that = >>>ANCP messages may only be sent or received on particular VLANs, but = >>>that is just an extra ACL, and each implementation can add as much = >>>security as needed and this should maybe not be in a standard ANCP MIB. >>> >>>Do you agree with this? >>> >>>Thanks for the review, all comments are very welcome. >>> >>>regards, >>>Stefaan >>> >>> >>>Freudenberger, Markus wrote: >>> >>> >>> >>>>Hi all, >>>> >>>>looking into the actual ancp-mib draft, I am misssing the following: >>>> >>>>1) the possibilty to configure the IP address on the AN for the control= channel as it is already defined for the peer NAS. This implies adding add= itional entries into the ancpAnCurrentSessionTable for reading the control = channel ip address of the NAS. >>>> >>>>2) the possibility to configure the allocation of control channel(s) to= a physical interface with VPI/VCI resp. C-/S-VAN-ID values and Qos/CoS set= ting. = >>>> >>>>Both is required to allow the EMS the setup of the control channel with= SNMP and this is described in Section 6 of the ancp framework document any= way (See below). = >>>> >>>>----------------------- snip from draft-ietf-ancp-framework-04.txt >>>>----------------------- 6. Management Related Requirements >>>> >>>> o It must be possible to configure the following parameters on the >>>> Access Node and the NAS: >>>> >>>> * Parameters related to the Control Channel transport method: >>>> these include the VPI/VCI and transport characteristics (e.g. >>>> VBR-rt or CBR) for ATM networks or the C-VLAN ID and S-VLAN ID >>>> and p-bit marking for Ethernet networks; >>>> >>>> * Parameters related to the Control Channel itself: these include >>>> the IP address of the IP interface on the Access Node and the >>>> NAS >>>>----------------------- snip from draft-ietf-ancp-framework-04.txt >>>>----------------------- >>>> >>>>Any comments? >>>> >>>>Regards >>>>Markus Freudenberger >>>> >>>>T-Systems Enterprise Services GmbH >>>>Systems Integration >>>>Telco Project & Design >>>>Line of Business Networks & Processes Technology Consultant = >>>>Deutsche-Telekom-Allee 7, D-64295 Darmstadt >>>>+49 6151 937-3679 (Phone) >>>>+49 6151 937-19875 (Fax) >>>>+49 521 5224 5816 (PC-Fax) >>>>E-Mail: mailto:markus.freudenberger@t-systems.com >>>>Internet: http://t-systems.com >>>> >>>> >>>> >>>> >>>> >>>>>T-Systems Enterprise Services GmbH >>>>>Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: = >>>>>Reinhard Clemens (Vorsitzender)*, Helmut Binder, Albert Henn, Olaf = >>>>>Heyden*, Katrin Horstmann, Wilfried Peters*, Dr. Herbert Schaaff*, = >>>>>Zvezdana Seeger* >>>>>Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der >>>>>Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 = >>>>>*Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG >>>>> >>>> >>>>Notice: This transmittal and/or attachments may be privileged or confid= ential. If you are not the intended recipient, you are hereby notified that= you have received this transmittal in error; any review, dissemination, or= copying is strictly prohibited. If you received this transmittal in error,= please notify us immediately by reply and immediately delete this message = and all its attachments. Thank you. >>>>T-Systems - Business flexibility >>>> >>>> >>>>_______________________________________________ >>>>ANCP mailing list >>>>ANCP@ietf.org >>>>http://www.ietf.org/mailman/listinfo/ancp >>> >>>_______________________________________________ >>>ANCP mailing list >>>ANCP@ietf.org >>>http://www.ietf.org/mailman/listinfo/ancp >> >> > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > http://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Feb 20 08:05:11 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBF0228C784; Wed, 20 Feb 2008 08:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.037 X-Spam-Level: X-Spam-Status: No, score=0.037 tagged_above=-999 required=5 tests=[AWL=-0.922, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PqYGkPhHyeT; Wed, 20 Feb 2008 08:05:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB1528C243; Wed, 20 Feb 2008 08:05:10 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 888C528C200 for ; Wed, 20 Feb 2008 08:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WegvbFmwfWGN for ; Wed, 20 Feb 2008 08:05:06 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 272903A68F3 for ; Wed, 20 Feb 2008 08:05:01 -0800 (PST) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Wed, 20 Feb 2008 17:04:56 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Feb 2008 17:04:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 17:04:54 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C81F78C@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <83153A1EB675AF4F82E134FA27F95F6702F9C8D0@ilptex01.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] missing items in the ancp-mib draft Thread-Index: AchzxBilFbylKEI0ToOjIeujZ3bQPgADPzwgAACmtpA= References: <1B6169C658325341A3B8066E23919E1C81F76F@S4DE8PSAANK.mitte.t-com.de><47B55F0E.7040205@alcatel-lucent.be><83153A1EB675AF4F82E134FA27F95F6702F354FA@ilptex01.ecitele.com><47B94869.8030905@alcatel-lucent.be><1B6169C658325341A3B8066E23919E1C81F782@S4DE8PSAANK.mitte.t-com.de><47BAE191.5040406@alcatel-lucent.be><1B6169C658325341A3B8066E23919E1C81F785@S4DE8PSAANK.mitte.t-com.de> <47BC2A44.4050104@alcatel-lucent.be> <83153A1EB675AF4F82E134FA27F95F6702F9C8D0@ilptex01.ecitele.com> From: "Freudenberger, Markus" To: , X-OriginalArrivalTime: 20 Feb 2008 16:04:55.0469 (UTC) FILETIME=[5581BDD0:01C873DA] Cc: "Haag, T" , "Busser, M" , ancp@ietf.org Subject: Re: [ANCP] missing items in the ancp-mib draft X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org All, Stefaan, you are right, but what we still need in the ANCP-MIB is the assoc= iation between the session and the layer 2 transport medium (ATM/VLAN) toge= ther with the physical interface. Moti's proposal would possibly allow that but we may need to determine if t= he bridge-mib really achieves all requirements. Assuming Moti thinks about the dot1dBasePortTable (1.3.6.1.2.1.17.1.4) from= the BRIDGE-MIB, there should also be described, how to address the underla= ying entity, e.g. ATM-PVC, and its parameters. = Regards Markus -----Urspr=FCngliche Nachricht----- Von: Moti Morgenstern [mailto:Moti.Morgenstern@ecitele.com] = Gesendet: Mittwoch, 20. Februar 2008 16:05 An: Stefaan DE CNODDER; Freudenberger, Markus Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org Betreff: RE: [ANCP] missing items in the ancp-mib draft Hi Markus & Stefaan, I think that it is more correct to associate the ANCP session with a bridge= port identifier. This is cleaner because then the IETF bridge MIB provides= the information regarding to the underlaying entity, which can perfectly b= e ATM PVC. Regards, Moti = -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Ste= faan DE CNODDER Sent: Wednesday, February 20, 2008 3:25 PM To: Freudenberger, Markus Cc: Haag, T; Busser,M; ancp@ietf.org Subject: Re: [ANCP] missing items in the ancp-mib draft Markus, Thinking further about this: S/C VLAN, p-bit, VPI/VCI can be added to the c= ofiguration per session, but not the QoS class for VPI/VCI. = Because if a PVC is used for 10 ANCP sessions, then it cannot be that one s= ession uses this PVC as UBR and another session as CBR. Also CBR requires = extra parameters like a bandwidth, and VBR even requires more like leaky bu= cket sizes, ... This all looks very specific ATM configuration not to be p= art of the ANCP MIB. So it is Ok for you to add the following objects to the configuration of a = session: S-VLAN C-VLAN p-bits VPI VCI Without QoS regards, Stefaan Freudenberger, Markus wrote: > Hi Stefaan, > = > the ancp session runs in the subnet as the configured VLAN. > = > Example configuration: = > = > AN NAS > ----------------------------------- > Bridge-port 1 1 > S-VLAN-ID 10 10 > C-VLAN-ID 10 10 > prio 7 7 > VPI 32 32 = > VCI 32 32 > QoS CBR CBR > IP-address 192.168.0.1/30 192.168.0.2/30 > ... > = > regards > Markus = > = > = > -----Urspr=FCngliche Nachricht----- > Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] > Gesendet: Dienstag, 19. Februar 2008 15:03 > An: Freudenberger, Markus > Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org > Betreff: Re: [ANCP] missing items in the ancp-mib draft > = > = > Hi Markus, > = > Indeed, ANCP is just one application that uses IP, and as soon the ANCP p= acket is encapsulated into an IP packet, it goes to the IP layer where it i= s treated like any other IP packet. > = > Suppose in ancpAnSessionConfigTable, an attribute VLAN is added, and I co= nfigure this VLAN equal to 100. Ok, the AN can sent then the ANCP packet t= o VLAN 100 (even though the IP routing table says that the best path to the= NAS IP address is via another VLAN), then my question is: = > what will be the MAC destination address of this IP packet, i.e., to whic= h IP address has the AN to send an ARP request to learn the MAC destination= address to be used for the ANCP packet? Knowing the VLAN ID is just not s= ufficient according to me. Either the NAS IP address MUST be in the subnet= as the configured VLAN (in which case the ARP is directly to the NAS IP ad= dress), or an IP lookup is done that results in a next-hop with correspondi= ng outgoing interface (=3DVLAN, PVC, ...). In the latter case, no VLAN is = needed in ancpAnSessionConfigTable because the IP lookup will automatically= give the VLAN. > = > For me both options are Ok, I just want to know how it has to work. > = > regards, > Stefaan > = > = > Freudenberger, Markus wrote: > = > = >>Moti, Stefaan, >> >>I agree with Moti's comments. = >>See my further comments to Stefaans statemtens inline, marked with "[MF]". >> >>Are there views from other people? >> >>regards >>Markus >> >>-----Urspr=FCngliche Nachricht----- >>Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] >>Gesendet: Montag, 18. Februar 2008 09:57 >>An: Moti Morgenstern; Freudenberger, Markus >>Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org >>Betreff: Re: [ANCP] missing items in the ancp-mib draft >> >> >>Moti, Markus, >> >>Moti Morgenstern wrote: >> >> >> >>>Hi, >>> >>>I think what Markus wrote is pretty correct. There should be, for exampl= e, a MIB for associating ANCP session with "ANCP VLAN". So, if that MIB is = already available, in already existing RFCs, then the ANCP MIB should inclu= de a section describing that as part of the "Relationship to Other MIB Modu= les", as done with the interfaces MIB. That will allow software engineers (= even if not members in our honorable ANCP WG) to see the whole picture. How= ever, if such a MIB is not available, then obviously the ANCP MIB should de= scribe what is the gap and define the MIB for filling it. = >>> >>>More specifically (and please correct me if I'm wrong): >>>- I do not recall a MIB for ATM PVCs that assumes single VC with multipl= exed services. However, in this case I think that we do not need such a MIB= because the ANCP control channel should actually be associated with bridge= port (and that bridge port has a MIB that provides the information on the = underlying L2). The question is how does the EMS associate the ANCP control= channel with a specific bridge port? >> >> >>An informational text can be added to explain how IP/ANCP packets are to = be routed but there is no formal linking with any other MIB. How the IP la= yer is configured is independent from how the protocol is configured. >> >>[MF] >>Stefaan, do you mean it is independent because ANCP is one of many other = applications which uses IP? If yes, you are right but the IP layer is essen= tial for ANCP (as the architecture chooses TCP/IP as a tranpsort medium) an= d as a consequence it is also essential to configure it and associate it wi= th a certain ANCP session from an EMS. This has to be mentioned somehow in = the document. I don't see a problem to create a reference to an RFC and/or = a MIB which provides these capabilities. But it is still needed to define = the link between the IP layer and ANCP session. >>[MF] >> >> >>For me it is also fine that ANCP packets are not routed in the AN but tha= t ANCP is bound to a certain interface (=3DVLAN or PVC) like it is for inst= ance with OSPF. But then the configured NAS IP address in the AN must be a= directly attached IP address, if the NAS IP address is not directly attach= ed, then the AN does not know which IP address to ARP (which it normally ge= ts from the next-hop of the matching route). >> >>When ANCP bypasses routing, VLAN-ID or PVC (with some extra attributes on= ly specific for ANCP packets like for instance p-bits) could be configured = in ancpAnSessionConfigTable. >> >>For me both options are fine, but if the second option is selected, the t= he framework draft should also mention this limitation (which should not be= a problem if we all agree I suspect). >> >>[MF] >>Sorry but I cannot indicate the options. Which limitation do you mean? = >>Anyway, I think the ANCP packets are not routed in the AN, they are termi= nated and the next IP hop is the NAS. The ancp framework document states fo= r this purpose: >>... >> o Control Channel: a bidirectional IP communication interface >> between the controller function (in the NAS) and the reporting/ >> enforcement function (in the AN). It is assumed that this >> interface is configured (rather than discovered) on the AN and the >> NAS. >>... >>and >>... >> o The Control Channel MUST be terminated at the Access Node. >>... >> >>To summarize, I only see the option to add additional attributes into the= ancpAnSessionConfigTable for layer 2 connection parameters (VLAN, VCC, QoS= class, priority) per session. = >>[MF] >> >>What is your preference? >> >> >> >> >>>- Stefaan says that "ANCP are IP packets originated from an IP address i= n the AN" and that's correct. But how does the EMS configure that address? = How does the EMS associate it with one of possibly multiple sessions? >>> >> >> >>It is the IP routing table that associates an ANCP packet (IP packet) to = a certain outgoing interface. The AN IP address is not configured per sess= ion but you can see the selected IP address in ancpAnCurrentSessionTable. = Typically, when a device generates an IP packet, its IP source address is u= sually set to the IP address of the outgoing IP interface. When the AN onl= y has 1 IP address (after all it is not a router), then it is straitforward. >> >>[MF] >>I disagree, the AN has more than 1 IP address (e. g. for telnet/SNMP), so= we have to differentiate here and if one can see the IP addess for a sessi= on in the ancpAnCurrentSessionTable, someone has to configure it somewhere,= right? = >>[MF] >> >>regards, >>Stefaan >> >> >> >> >>>I'll be glad to hear more opinions on those issues. >>> >>>Regards, >>>Moti >>> >>> >>>-----Original Message----- >>>From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = >>>Of Stefaan DE CNODDER >>>Sent: Friday, February 15, 2008 11:45 AM >>>To: Freudenberger, Markus >>>Cc: Haag, T; Busser,M; ancp@ietf.org >>>Subject: Re: [ANCP] missing items in the ancp-mib draft >>> >>> >>>Hi Markus, >>> >>>The parameters related to control channel has been intentionally not = >>>been included in the ANCP MIB because these attributes are to be = >>>configured in other MIBs. For instance, if the VLAN on which ANCP is = >>>running needs p-bit 5, then that is to be configured in the = >>>corresponding ethernet MIB where VLANs are configured. The same for >>>PVCs: I guess there are ATM MIBs where the attributes of all the PVCs = >>>can be configured. >>> >>>Then you also need the selection of the VLAN or PVC to be used for ANCP. = >>> Actually, ANCP are IP packets originated from an IP address in the = >>>AN, and transmitted like any other IP packet, i.e., the AN performs = >>>an IP lookup in its routing table. So if the correct routing cannot = >>>be achieved because the IP address of the directly attached interface = >>>of the "ANCP VLAN" is not used as NAS address, then an appriopriate = >>>route has to be configured such that these packets are going to the = >>>VLAN on which they should be. However, also this "routing = >>>information" (in whatever form) is to be configured in other MIBs than t= he ANCP MIB. >>> >>>Look it like this in case of ethernet: if the AN generates an ANCP = >>>message to the NAS, then the ANCP message is put in an ethernet = >>>frame, this ethernet frame needs a MAC destination address. To get = >>>the MAC destination address, the AN has to send an ARP to an IP = >>>address. This IP address is the next-hop IP address, which it gets = >>>from the routing information. It can be a next-hop of a route, or in = >>>case the NAS IP address is directly attached, the IP packet matches the = direct route. >>> >>>So I have the feeling that this "routing information" for ANCP can = >>>exist in multiple forms: >>>(1) a route with next-hop, or directly attached >>>(2) a VLAN (so no next-hop and then the NAS IP must be directly = >>>attached for sending an ARP). >>>- ... >>> >>>So I have the feeling that this just do not belong to an ANCP MIB. = >>>For sure option (1) should not be in the ANCP MIB, (2) could be added = >>>but since a generic solution anyhow requires (1), I do not see the = >>>need to add something in the ANCP MIB. >>> >>>Extra filters in the ANCP MIB could be added like for instance that = >>>ANCP messages may only be sent or received on particular VLANs, but = >>>that is just an extra ACL, and each implementation can add as much = >>>security as needed and this should maybe not be in a standard ANCP MIB. >>> >>>Do you agree with this? >>> >>>Thanks for the review, all comments are very welcome. >>> >>>regards, >>>Stefaan >>> >>> >>>Freudenberger, Markus wrote: >>> >>> >>> >>>>Hi all, >>>> >>>>looking into the actual ancp-mib draft, I am misssing the following: >>>> >>>>1) the possibilty to configure the IP address on the AN for the control= channel as it is already defined for the peer NAS. This implies adding add= itional entries into the ancpAnCurrentSessionTable for reading the control = channel ip address of the NAS. >>>> >>>>2) the possibility to configure the allocation of control channel(s) to= a physical interface with VPI/VCI resp. C-/S-VAN-ID values and Qos/CoS set= ting. = >>>> >>>>Both is required to allow the EMS the setup of the control channel with= SNMP and this is described in Section 6 of the ancp framework document any= way (See below). = >>>> >>>>----------------------- snip from draft-ietf-ancp-framework-04.txt >>>>----------------------- 6. Management Related Requirements >>>> >>>> o It must be possible to configure the following parameters on the >>>> Access Node and the NAS: >>>> >>>> * Parameters related to the Control Channel transport method: >>>> these include the VPI/VCI and transport characteristics (e.g. >>>> VBR-rt or CBR) for ATM networks or the C-VLAN ID and S-VLAN ID >>>> and p-bit marking for Ethernet networks; >>>> >>>> * Parameters related to the Control Channel itself: these include >>>> the IP address of the IP interface on the Access Node and the >>>> NAS >>>>----------------------- snip from draft-ietf-ancp-framework-04.txt >>>>----------------------- >>>> >>>>Any comments? >>>> >>>>Regards >>>>Markus Freudenberger >>>> >>>>T-Systems Enterprise Services GmbH >>>>Systems Integration >>>>Telco Project & Design >>>>Line of Business Networks & Processes Technology Consultant = >>>>Deutsche-Telekom-Allee 7, D-64295 Darmstadt >>>>+49 6151 937-3679 (Phone) >>>>+49 6151 937-19875 (Fax) >>>>+49 521 5224 5816 (PC-Fax) >>>>E-Mail: mailto:markus.freudenberger@t-systems.com >>>>Internet: http://t-systems.com >>>> >>>> >>>> >>>> >>>> >>>>>T-Systems Enterprise Services GmbH >>>>>Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: = >>>>>Reinhard Clemens (Vorsitzender)*, Helmut Binder, Albert Henn, Olaf = >>>>>Heyden*, Katrin Horstmann, Wilfried Peters*, Dr. Herbert Schaaff*, = >>>>>Zvezdana Seeger* >>>>>Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der >>>>>Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 = >>>>>*Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG >>>>> >>>> >>>>Notice: This transmittal and/or attachments may be privileged or confid= ential. If you are not the intended recipient, you are hereby notified that= you have received this transmittal in error; any review, dissemination, or= copying is strictly prohibited. If you received this transmittal in error,= please notify us immediately by reply and immediately delete this message = and all its attachments. Thank you. >>>>T-Systems - Business flexibility >>>> >>>> >>>>_______________________________________________ >>>>ANCP mailing list >>>>ANCP@ietf.org >>>>http://www.ietf.org/mailman/listinfo/ancp >>> >>>_______________________________________________ >>>ANCP mailing list >>>ANCP@ietf.org >>>http://www.ietf.org/mailman/listinfo/ancp >> >> > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > http://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Feb 20 23:08:22 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76C0328C948; Wed, 20 Feb 2008 23:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.366 X-Spam-Level: X-Spam-Status: No, score=0.366 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snsIEJgpzZMN; Wed, 20 Feb 2008 23:08:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25D628C8C5; Wed, 20 Feb 2008 23:08:20 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E746228C2B2 for ; Wed, 20 Feb 2008 23:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAHYx5rIsj5Q for ; Wed, 20 Feb 2008 23:08:18 -0800 (PST) Received: from eci-iron1.ecitele.com (eci-iron1.ecitele.com [147.234.242.117]) by core3.amsl.com (Postfix) with ESMTP id D7A3428C8E1 for ; Wed, 20 Feb 2008 23:08:16 -0800 (PST) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 21 Feb 2008 09:36:28 +0200 Received: from ilptexch01.ecitele.com ([172.31.244.40]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Feb 2008 09:08:12 +0200 Received: from ILPTMAIL01.ecitele.com (147.234.245.210) by ilptexch01.ecitele.com (172.31.244.40) with Microsoft SMTP Server id 8.1.240.5; Thu, 21 Feb 2008 09:08:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 09:08:11 +0200 Message-ID: <83153A1EB675AF4F82E134FA27F95F6702F9CA89@ilptex01.ecitele.com> In-Reply-To: <1B6169C658325341A3B8066E23919E1C81F78C@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] missing items in the ancp-mib draft Thread-Index: AchzxBilFbylKEI0ToOjIeujZ3bQPgADPzwgAACmtpAAINRcIA== References: <1B6169C658325341A3B8066E23919E1C81F76F@S4DE8PSAANK.mitte.t-com.de><47B55F0E.7040205@alcatel-lucent.be><83153A1EB675AF4F82E134FA27F95F6702F354FA@ilptex01.ecitele.com><47B94869.8030905@alcatel-lucent.be><1B6169C658325341A3B8066E23919E1C81F782@S4DE8PSAANK.mitte.t-com.de><47BAE191.5040406@alcatel-lucent.be><1B6169C658325341A3B8066E23919E1C81F785@S4DE8PSAANK.mitte.t-com.de> <47BC2A44.4050104@alcatel-lucent.be> <83153A1EB675AF4F82E134FA27F95F6702F9C8D0@ilptex01.ecitele.com> <1B6169C658325341A3B8066E23919E1C81F78C@S4DE8PSAANK.mitte.t-com.de> From: Moti Morgenstern To: "Freudenberger, Markus" , X-OriginalArrivalTime: 21 Feb 2008 07:08:12.0186 (UTC) FILETIME=[854477A0:01C87458] Cc: "Haag, T" , "Busser, M" , ancp@ietf.org Subject: Re: [ANCP] missing items in the ancp-mib draft X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi, Regarding to "how to address the underlying entity", I think that we have t= wo objects in dot1dBasePortTable that provide the link to the underlying en= tity. In case the underlying entity is addressable by a unique ifIndex value then= dot1dBasePortIfIndex is enough. If that is not the case (e.g., a PVC is ad= dressed also by VPI and VCI and there might be multiple PVCs per ifIndex) t= hen dot1dBasePortCircuit can be used. = Anyway, I believe attaching the ANCP flow to a bridge port and not directly= to the lower layer is more "elegant". Regards, Moti -----Original Message----- From: Freudenberger, Markus [mailto:Markus.Freudenberger@t-systems.com] = Sent: Wednesday, February 20, 2008 6:05 PM To: Moti Morgenstern; stefaan.de_cnodder@alcatel-lucent.be Cc: Haag, T; Busser, M; ancp@ietf.org Subject: AW: [ANCP] missing items in the ancp-mib draft All, Stefaan, you are right, but what we still need in the ANCP-MIB is the assoc= iation between the session and the layer 2 transport medium (ATM/VLAN) toge= ther with the physical interface. Moti's proposal would possibly allow that but we may need to determine if t= he bridge-mib really achieves all requirements. Assuming Moti thinks about the dot1dBasePortTable (1.3.6.1.2.1.17.1.4) from= the BRIDGE-MIB, there should also be described, how to address the underla= ying entity, e.g. ATM-PVC, and its parameters. = Regards Markus -----Urspr=FCngliche Nachricht----- Von: Moti Morgenstern [mailto:Moti.Morgenstern@ecitele.com] = Gesendet: Mittwoch, 20. Februar 2008 16:05 An: Stefaan DE CNODDER; Freudenberger, Markus Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org Betreff: RE: [ANCP] missing items in the ancp-mib draft Hi Markus & Stefaan, I think that it is more correct to associate the ANCP session with a bridge= port identifier. This is cleaner because then the IETF bridge MIB provides= the information regarding to the underlaying entity, which can perfectly b= e ATM PVC. Regards, Moti = -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Ste= faan DE CNODDER Sent: Wednesday, February 20, 2008 3:25 PM To: Freudenberger, Markus Cc: Haag, T; Busser,M; ancp@ietf.org Subject: Re: [ANCP] missing items in the ancp-mib draft Markus, Thinking further about this: S/C VLAN, p-bit, VPI/VCI can be added to the c= ofiguration per session, but not the QoS class for VPI/VCI. = Because if a PVC is used for 10 ANCP sessions, then it cannot be that one s= ession uses this PVC as UBR and another session as CBR. Also CBR requires = extra parameters like a bandwidth, and VBR even requires more like leaky bu= cket sizes, ... This all looks very specific ATM configuration not to be p= art of the ANCP MIB. So it is Ok for you to add the following objects to the configuration of a = session: S-VLAN C-VLAN p-bits VPI VCI Without QoS regards, Stefaan Freudenberger, Markus wrote: > Hi Stefaan, > = > the ancp session runs in the subnet as the configured VLAN. > = > Example configuration: = > = > AN NAS > ----------------------------------- > Bridge-port 1 1 > S-VLAN-ID 10 10 > C-VLAN-ID 10 10 > prio 7 7 > VPI 32 32 = > VCI 32 32 > QoS CBR CBR > IP-address 192.168.0.1/30 192.168.0.2/30 > ... > = > regards > Markus = > = > = > -----Urspr=FCngliche Nachricht----- > Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] > Gesendet: Dienstag, 19. Februar 2008 15:03 > An: Freudenberger, Markus > Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org > Betreff: Re: [ANCP] missing items in the ancp-mib draft > = > = > Hi Markus, > = > Indeed, ANCP is just one application that uses IP, and as soon the ANCP p= acket is encapsulated into an IP packet, it goes to the IP layer where it i= s treated like any other IP packet. > = > Suppose in ancpAnSessionConfigTable, an attribute VLAN is added, and I co= nfigure this VLAN equal to 100. Ok, the AN can sent then the ANCP packet t= o VLAN 100 (even though the IP routing table says that the best path to the= NAS IP address is via another VLAN), then my question is: = > what will be the MAC destination address of this IP packet, i.e., to whic= h IP address has the AN to send an ARP request to learn the MAC destination= address to be used for the ANCP packet? Knowing the VLAN ID is just not s= ufficient according to me. Either the NAS IP address MUST be in the subnet= as the configured VLAN (in which case the ARP is directly to the NAS IP ad= dress), or an IP lookup is done that results in a next-hop with correspondi= ng outgoing interface (=3DVLAN, PVC, ...). In the latter case, no VLAN is = needed in ancpAnSessionConfigTable because the IP lookup will automatically= give the VLAN. > = > For me both options are Ok, I just want to know how it has to work. > = > regards, > Stefaan > = > = > Freudenberger, Markus wrote: > = > = >>Moti, Stefaan, >> >>I agree with Moti's comments. = >>See my further comments to Stefaans statemtens inline, marked with "[MF]". >> >>Are there views from other people? >> >>regards >>Markus >> >>-----Urspr=FCngliche Nachricht----- >>Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] >>Gesendet: Montag, 18. Februar 2008 09:57 >>An: Moti Morgenstern; Freudenberger, Markus >>Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org >>Betreff: Re: [ANCP] missing items in the ancp-mib draft >> >> >>Moti, Markus, >> >>Moti Morgenstern wrote: >> >> >> >>>Hi, >>> >>>I think what Markus wrote is pretty correct. There should be, for exampl= e, a MIB for associating ANCP session with "ANCP VLAN". So, if that MIB is = already available, in already existing RFCs, then the ANCP MIB should inclu= de a section describing that as part of the "Relationship to Other MIB Modu= les", as done with the interfaces MIB. That will allow software engineers (= even if not members in our honorable ANCP WG) to see the whole picture. How= ever, if such a MIB is not available, then obviously the ANCP MIB should de= scribe what is the gap and define the MIB for filling it. = >>> >>>More specifically (and please correct me if I'm wrong): >>>- I do not recall a MIB for ATM PVCs that assumes single VC with multipl= exed services. However, in this case I think that we do not need such a MIB= because the ANCP control channel should actually be associated with bridge= port (and that bridge port has a MIB that provides the information on the = underlying L2). The question is how does the EMS associate the ANCP control= channel with a specific bridge port? >> >> >>An informational text can be added to explain how IP/ANCP packets are to = be routed but there is no formal linking with any other MIB. How the IP la= yer is configured is independent from how the protocol is configured. >> >>[MF] >>Stefaan, do you mean it is independent because ANCP is one of many other = applications which uses IP? If yes, you are right but the IP layer is essen= tial for ANCP (as the architecture chooses TCP/IP as a tranpsort medium) an= d as a consequence it is also essential to configure it and associate it wi= th a certain ANCP session from an EMS. This has to be mentioned somehow in = the document. I don't see a problem to create a reference to an RFC and/or = a MIB which provides these capabilities. But it is still needed to define = the link between the IP layer and ANCP session. >>[MF] >> >> >>For me it is also fine that ANCP packets are not routed in the AN but tha= t ANCP is bound to a certain interface (=3DVLAN or PVC) like it is for inst= ance with OSPF. But then the configured NAS IP address in the AN must be a= directly attached IP address, if the NAS IP address is not directly attach= ed, then the AN does not know which IP address to ARP (which it normally ge= ts from the next-hop of the matching route). >> >>When ANCP bypasses routing, VLAN-ID or PVC (with some extra attributes on= ly specific for ANCP packets like for instance p-bits) could be configured = in ancpAnSessionConfigTable. >> >>For me both options are fine, but if the second option is selected, the t= he framework draft should also mention this limitation (which should not be= a problem if we all agree I suspect). >> >>[MF] >>Sorry but I cannot indicate the options. Which limitation do you mean? = >>Anyway, I think the ANCP packets are not routed in the AN, they are termi= nated and the next IP hop is the NAS. The ancp framework document states fo= r this purpose: >>... >> o Control Channel: a bidirectional IP communication interface >> between the controller function (in the NAS) and the reporting/ >> enforcement function (in the AN). It is assumed that this >> interface is configured (rather than discovered) on the AN and the >> NAS. >>... >>and >>... >> o The Control Channel MUST be terminated at the Access Node. >>... >> >>To summarize, I only see the option to add additional attributes into the= ancpAnSessionConfigTable for layer 2 connection parameters (VLAN, VCC, QoS= class, priority) per session. = >>[MF] >> >>What is your preference? >> >> >> >> >>>- Stefaan says that "ANCP are IP packets originated from an IP address i= n the AN" and that's correct. But how does the EMS configure that address? = How does the EMS associate it with one of possibly multiple sessions? >>> >> >> >>It is the IP routing table that associates an ANCP packet (IP packet) to = a certain outgoing interface. The AN IP address is not configured per sess= ion but you can see the selected IP address in ancpAnCurrentSessionTable. = Typically, when a device generates an IP packet, its IP source address is u= sually set to the IP address of the outgoing IP interface. When the AN onl= y has 1 IP address (after all it is not a router), then it is straitforward. >> >>[MF] >>I disagree, the AN has more than 1 IP address (e. g. for telnet/SNMP), so= we have to differentiate here and if one can see the IP addess for a sessi= on in the ancpAnCurrentSessionTable, someone has to configure it somewhere,= right? = >>[MF] >> >>regards, >>Stefaan >> >> >> >> >>>I'll be glad to hear more opinions on those issues. >>> >>>Regards, >>>Moti >>> >>> >>>-----Original Message----- >>>From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = >>>Of Stefaan DE CNODDER >>>Sent: Friday, February 15, 2008 11:45 AM >>>To: Freudenberger, Markus >>>Cc: Haag, T; Busser,M; ancp@ietf.org >>>Subject: Re: [ANCP] missing items in the ancp-mib draft >>> >>> >>>Hi Markus, >>> >>>The parameters related to control channel has been intentionally not = >>>been included in the ANCP MIB because these attributes are to be = >>>configured in other MIBs. For instance, if the VLAN on which ANCP is = >>>running needs p-bit 5, then that is to be configured in the = >>>corresponding ethernet MIB where VLANs are configured. The same for >>>PVCs: I guess there are ATM MIBs where the attributes of all the PVCs = >>>can be configured. >>> >>>Then you also need the selection of the VLAN or PVC to be used for ANCP. = >>> Actually, ANCP are IP packets originated from an IP address in the = >>>AN, and transmitted like any other IP packet, i.e., the AN performs = >>>an IP lookup in its routing table. So if the correct routing cannot = >>>be achieved because the IP address of the directly attached interface = >>>of the "ANCP VLAN" is not used as NAS address, then an appriopriate = >>>route has to be configured such that these packets are going to the = >>>VLAN on which they should be. However, also this "routing = >>>information" (in whatever form) is to be configured in other MIBs than t= he ANCP MIB. >>> >>>Look it like this in case of ethernet: if the AN generates an ANCP = >>>message to the NAS, then the ANCP message is put in an ethernet = >>>frame, this ethernet frame needs a MAC destination address. To get = >>>the MAC destination address, the AN has to send an ARP to an IP = >>>address. This IP address is the next-hop IP address, which it gets = >>>from the routing information. It can be a next-hop of a route, or in = >>>case the NAS IP address is directly attached, the IP packet matches the = direct route. >>> >>>So I have the feeling that this "routing information" for ANCP can = >>>exist in multiple forms: >>>(1) a route with next-hop, or directly attached >>>(2) a VLAN (so no next-hop and then the NAS IP must be directly = >>>attached for sending an ARP). >>>- ... >>> >>>So I have the feeling that this just do not belong to an ANCP MIB. = >>>For sure option (1) should not be in the ANCP MIB, (2) could be added = >>>but since a generic solution anyhow requires (1), I do not see the = >>>need to add something in the ANCP MIB. >>> >>>Extra filters in the ANCP MIB could be added like for instance that = >>>ANCP messages may only be sent or received on particular VLANs, but = >>>that is just an extra ACL, and each implementation can add as much = >>>security as needed and this should maybe not be in a standard ANCP MIB. >>> >>>Do you agree with this? >>> >>>Thanks for the review, all comments are very welcome. >>> >>>regards, >>>Stefaan >>> >>> >>>Freudenberger, Markus wrote: >>> >>> >>> >>>>Hi all, >>>> >>>>looking into the actual ancp-mib draft, I am misssing the following: >>>> >>>>1) the possibilty to configure the IP address on the AN for the control= channel as it is already defined for the peer NAS. This implies adding add= itional entries into the ancpAnCurrentSessionTable for reading the control = channel ip address of the NAS. >>>> >>>>2) the possibility to configure the allocation of control channel(s) to= a physical interface with VPI/VCI resp. C-/S-VAN-ID values and Qos/CoS set= ting. = >>>> >>>>Both is required to allow the EMS the setup of the control channel with= SNMP and this is described in Section 6 of the ancp framework document any= way (See below). = >>>> >>>>----------------------- snip from draft-ietf-ancp-framework-04.txt >>>>----------------------- 6. Management Related Requirements >>>> >>>> o It must be possible to configure the following parameters on the >>>> Access Node and the NAS: >>>> >>>> * Parameters related to the Control Channel transport method: >>>> these include the VPI/VCI and transport characteristics (e.g. >>>> VBR-rt or CBR) for ATM networks or the C-VLAN ID and S-VLAN ID >>>> and p-bit marking for Ethernet networks; >>>> >>>> * Parameters related to the Control Channel itself: these include >>>> the IP address of the IP interface on the Access Node and the >>>> NAS >>>>----------------------- snip from draft-ietf-ancp-framework-04.txt >>>>----------------------- >>>> >>>>Any comments? >>>> >>>>Regards >>>>Markus Freudenberger >>>> >>>>T-Systems Enterprise Services GmbH >>>>Systems Integration >>>>Telco Project & Design >>>>Line of Business Networks & Processes Technology Consultant = >>>>Deutsche-Telekom-Allee 7, D-64295 Darmstadt >>>>+49 6151 937-3679 (Phone) >>>>+49 6151 937-19875 (Fax) >>>>+49 521 5224 5816 (PC-Fax) >>>>E-Mail: mailto:markus.freudenberger@t-systems.com >>>>Internet: http://t-systems.com >>>> >>>> >>>> >>>> >>>> >>>>>T-Systems Enterprise Services GmbH >>>>>Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: = >>>>>Reinhard Clemens (Vorsitzender)*, Helmut Binder, Albert Henn, Olaf = >>>>>Heyden*, Katrin Horstmann, Wilfried Peters*, Dr. Herbert Schaaff*, = >>>>>Zvezdana Seeger* >>>>>Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der >>>>>Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 = >>>>>*Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG >>>>> >>>> >>>>Notice: This transmittal and/or attachments may be privileged or confid= ential. If you are not the intended recipient, you are hereby notified that= you have received this transmittal in error; any review, dissemination, or= copying is strictly prohibited. If you received this transmittal in error,= please notify us immediately by reply and immediately delete this message = and all its attachments. Thank you. >>>>T-Systems - Business flexibility >>>> >>>> >>>>_______________________________________________ >>>>ANCP mailing list >>>>ANCP@ietf.org >>>>http://www.ietf.org/mailman/listinfo/ancp >>> >>>_______________________________________________ >>>ANCP mailing list >>>ANCP@ietf.org >>>http://www.ietf.org/mailman/listinfo/ancp >> >> > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > http://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Feb 21 06:00:59 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE47728CAC8; Thu, 21 Feb 2008 06:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.186 X-Spam-Level: X-Spam-Status: No, score=0.186 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_39=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2Q24oWclLgk; Thu, 21 Feb 2008 06:00:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1DC728CAC7; Thu, 21 Feb 2008 06:00:54 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 549D328CAC4 for ; Thu, 21 Feb 2008 06:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTPkhpwXYAlR for ; Thu, 21 Feb 2008 06:00:51 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id C048D28CADC for ; Thu, 21 Feb 2008 06:00:49 -0800 (PST) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m1LDleRv011090; Thu, 21 Feb 2008 14:47:41 +0100 Received: from [172.31.131.165] ([172.31.131.165]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Thu, 21 Feb 2008 15:00:10 +0100 Message-ID: <47BD83E7.4040009@alcatel-lucent.be> Date: Thu, 21 Feb 2008 15:00:07 +0100 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: Moti Morgenstern References: <1B6169C658325341A3B8066E23919E1C81F76F@S4DE8PSAANK.mitte.t-com.de><47B55F0E.7040205@alcatel-lucent.be><83153A1EB675AF4F82E134FA27F95F6702F354FA@ilptex01.ecitele.com><47B94869.8030905@alcatel-lucent.be><1B6169C658325341A3B8066E23919E1C81F782@S4DE8PSAANK.mitte.t-com.de><47BAE191.5040406@alcatel-lucent.be><1B6169C658325341A3B8066E23919E1C81F785@S4DE8PSAANK.mitte.t-com.de> <47BC2A44.4050104@alcatel-lucent.be> <83153A1EB675AF4F82E134FA27F95F6702F9C8D0@ilptex01.ecitele.com> <1B6169C658325341A3B8066E23919E1C81F78C@S4DE8PSAANK.mitte.t-com.de> <83153A1EB675AF4F82E134FA27F95F6702F9CA89@ilptex01.ecitele.com> In-Reply-To: <83153A1EB675AF4F82E134FA27F95F6702F9CA89@ilptex01.ecitele.com> X-OriginalArrivalTime: 21 Feb 2008 14:00:10.0628 (UTC) FILETIME=[129B6440:01C87492] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "Haag, T" , "Busser, M" , ancp@ietf.org, "Freudenberger, Markus" Subject: Re: [ANCP] missing items in the ancp-mib draft X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi, I also think it is a good idea to refer to an interface in an existing = MIB like the bridge MIB, but ANCP runs on a VLAN and not an a bridge = port. A VLAN can be configured on multiple ports, so what is in this = case the bridge port? Does it mean that when ANCP has to run over S/C = VLAN 100/200, then S/C VLAN 100/200 gets a unique bridge port number to = be used for dot1dBasePort and then dot1dBasePortCircuit gets the value = 100 200 ? Is that how it works? If that's the case, then it looks very = good. regards, Stefaan Moti Morgenstern wrote: > Hi, > = > Regarding to "how to address the underlying entity", I think that we have= two objects in dot1dBasePortTable that provide the link to the underlying = entity. > = > In case the underlying entity is addressable by a unique ifIndex value th= en dot1dBasePortIfIndex is enough. If that is not the case (e.g., a PVC is = addressed also by VPI and VCI and there might be multiple PVCs per ifIndex)= then dot1dBasePortCircuit can be used. = > = > Anyway, I believe attaching the ANCP flow to a bridge port and not direct= ly to the lower layer is more "elegant". > = > Regards, Moti > -----Original Message----- > From: Freudenberger, Markus [mailto:Markus.Freudenberger@t-systems.com] = > Sent: Wednesday, February 20, 2008 6:05 PM > To: Moti Morgenstern; stefaan.de_cnodder@alcatel-lucent.be > Cc: Haag, T; Busser, M; ancp@ietf.org > Subject: AW: [ANCP] missing items in the ancp-mib draft > = > All, > = > Stefaan, you are right, but what we still need in the ANCP-MIB is the ass= ociation between the session and the layer 2 transport medium (ATM/VLAN) to= gether with the physical interface. > Moti's proposal would possibly allow that but we may need to determine if= the bridge-mib really achieves all requirements. > = > Assuming Moti thinks about the dot1dBasePortTable (1.3.6.1.2.1.17.1.4) fr= om the BRIDGE-MIB, there should also be described, how to address the under= laying entity, e.g. ATM-PVC, and its parameters. = > = > Regards > Markus > = > = > -----Urspr=FCngliche Nachricht----- > Von: Moti Morgenstern [mailto:Moti.Morgenstern@ecitele.com] = > Gesendet: Mittwoch, 20. Februar 2008 16:05 > An: Stefaan DE CNODDER; Freudenberger, Markus > Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org > Betreff: RE: [ANCP] missing items in the ancp-mib draft > = > Hi Markus & Stefaan, > = > I think that it is more correct to associate the ANCP session with a brid= ge port identifier. This is cleaner because then the IETF bridge MIB provid= es the information regarding to the underlaying entity, which can perfectly= be ATM PVC. > = > Regards, Moti > = > = > -----Original Message----- > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of S= tefaan DE CNODDER > Sent: Wednesday, February 20, 2008 3:25 PM > To: Freudenberger, Markus > Cc: Haag, T; Busser,M; ancp@ietf.org > Subject: Re: [ANCP] missing items in the ancp-mib draft > = > = > Markus, > = > Thinking further about this: S/C VLAN, p-bit, VPI/VCI can be added to the= cofiguration per session, but not the QoS class for VPI/VCI. = > Because if a PVC is used for 10 ANCP sessions, then it cannot be that one= session uses this PVC as UBR and another session as CBR. Also CBR require= s extra parameters like a bandwidth, and VBR even requires more like leaky = bucket sizes, ... This all looks very specific ATM configuration not to be= part of the ANCP MIB. > = > So it is Ok for you to add the following objects to the configuration of = a session: > = > S-VLAN > C-VLAN > p-bits > VPI > VCI > = > Without QoS > = > regards, > Stefaan > = > = > Freudenberger, Markus wrote: > = > = >>Hi Stefaan, >> >>the ancp session runs in the subnet as the configured VLAN. >> >>Example configuration: = >> >> AN NAS >>----------------------------------- >>Bridge-port 1 1 >>S-VLAN-ID 10 10 >>C-VLAN-ID 10 10 >>prio 7 7 >>VPI 32 32 = >>VCI 32 32 >>QoS CBR CBR >>IP-address 192.168.0.1/30 192.168.0.2/30 >>... >> >>regards >>Markus = >> >> >>-----Urspr=FCngliche Nachricht----- >>Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] >>Gesendet: Dienstag, 19. Februar 2008 15:03 >>An: Freudenberger, Markus >>Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org >>Betreff: Re: [ANCP] missing items in the ancp-mib draft >> >> >>Hi Markus, >> >>Indeed, ANCP is just one application that uses IP, and as soon the ANCP p= acket is encapsulated into an IP packet, it goes to the IP layer where it i= s treated like any other IP packet. >> >>Suppose in ancpAnSessionConfigTable, an attribute VLAN is added, and I co= nfigure this VLAN equal to 100. Ok, the AN can sent then the ANCP packet t= o VLAN 100 (even though the IP routing table says that the best path to the= NAS IP address is via another VLAN), then my question is: = >>what will be the MAC destination address of this IP packet, i.e., to whic= h IP address has the AN to send an ARP request to learn the MAC destination= address to be used for the ANCP packet? Knowing the VLAN ID is just not s= ufficient according to me. Either the NAS IP address MUST be in the subnet= as the configured VLAN (in which case the ARP is directly to the NAS IP ad= dress), or an IP lookup is done that results in a next-hop with correspondi= ng outgoing interface (=3DVLAN, PVC, ...). In the latter case, no VLAN is = needed in ancpAnSessionConfigTable because the IP lookup will automatically= give the VLAN. >> >>For me both options are Ok, I just want to know how it has to work. >> >>regards, >>Stefaan >> >> >>Freudenberger, Markus wrote: >> >> >> >>>Moti, Stefaan, >>> >>>I agree with Moti's comments. = >>>See my further comments to Stefaans statemtens inline, marked with "[MF]= ". >>> >>>Are there views from other people? >>> >>>regards >>>Markus >>> >>>-----Urspr=FCngliche Nachricht----- >>>Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] >>>Gesendet: Montag, 18. Februar 2008 09:57 >>>An: Moti Morgenstern; Freudenberger, Markus >>>Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org >>>Betreff: Re: [ANCP] missing items in the ancp-mib draft >>> >>> >>>Moti, Markus, >>> >>>Moti Morgenstern wrote: >>> >>> >>> >>> >>>>Hi, >>>> >>>>I think what Markus wrote is pretty correct. There should be, for examp= le, a MIB for associating ANCP session with "ANCP VLAN". So, if that MIB is= already available, in already existing RFCs, then the ANCP MIB should incl= ude a section describing that as part of the "Relationship to Other MIB Mod= ules", as done with the interfaces MIB. That will allow software engineers = (even if not members in our honorable ANCP WG) to see the whole picture. Ho= wever, if such a MIB is not available, then obviously the ANCP MIB should d= escribe what is the gap and define the MIB for filling it. = >>>> >>>>More specifically (and please correct me if I'm wrong): >>>>- I do not recall a MIB for ATM PVCs that assumes single VC with multip= lexed services. However, in this case I think that we do not need such a MI= B because the ANCP control channel should actually be associated with bridg= e port (and that bridge port has a MIB that provides the information on the= underlying L2). The question is how does the EMS associate the ANCP contro= l channel with a specific bridge port? >>> >>> >>>An informational text can be added to explain how IP/ANCP packets are to= be routed but there is no formal linking with any other MIB. How the IP l= ayer is configured is independent from how the protocol is configured. >>> >>>[MF] >>>Stefaan, do you mean it is independent because ANCP is one of many other= applications which uses IP? If yes, you are right but the IP layer is esse= ntial for ANCP (as the architecture chooses TCP/IP as a tranpsort medium) a= nd as a consequence it is also essential to configure it and associate it w= ith a certain ANCP session from an EMS. This has to be mentioned somehow in= the document. I don't see a problem to create a reference to an RFC and/or= a MIB which provides these capabilities. But it is still needed to define= the link between the IP layer and ANCP session. >>>[MF] >>> >>> >>>For me it is also fine that ANCP packets are not routed in the AN but th= at ANCP is bound to a certain interface (=3DVLAN or PVC) like it is for ins= tance with OSPF. But then the configured NAS IP address in the AN must be = a directly attached IP address, if the NAS IP address is not directly attac= hed, then the AN does not know which IP address to ARP (which it normally g= ets from the next-hop of the matching route). >>> >>>When ANCP bypasses routing, VLAN-ID or PVC (with some extra attributes o= nly specific for ANCP packets like for instance p-bits) could be configured= in ancpAnSessionConfigTable. >>> >>>For me both options are fine, but if the second option is selected, the = the framework draft should also mention this limitation (which should not b= e a problem if we all agree I suspect). >>> >>>[MF] >>>Sorry but I cannot indicate the options. Which limitation do you mean? = >>>Anyway, I think the ANCP packets are not routed in the AN, they are term= inated and the next IP hop is the NAS. The ancp framework document states f= or this purpose: >>>... >>> o Control Channel: a bidirectional IP communication interface >>> between the controller function (in the NAS) and the reporting/ >>> enforcement function (in the AN). It is assumed that this >>> interface is configured (rather than discovered) on the AN and the >>> NAS. >>>... >>>and >>>... >>> o The Control Channel MUST be terminated at the Access Node. >>>... >>> >>>To summarize, I only see the option to add additional attributes into th= e ancpAnSessionConfigTable for layer 2 connection parameters (VLAN, VCC, Qo= S class, priority) per session. = >>>[MF] >>> >>>What is your preference? >>> >>> >>> >>> >>> >>>>- Stefaan says that "ANCP are IP packets originated from an IP address = in the AN" and that's correct. But how does the EMS configure that address?= How does the EMS associate it with one of possibly multiple sessions? >>>> >>> >>> >>>It is the IP routing table that associates an ANCP packet (IP packet) to= a certain outgoing interface. The AN IP address is not configured per ses= sion but you can see the selected IP address in ancpAnCurrentSessionTable. = Typically, when a device generates an IP packet, its IP source address is = usually set to the IP address of the outgoing IP interface. When the AN on= ly has 1 IP address (after all it is not a router), then it is straitforwar= d. >>> >>>[MF] >>>I disagree, the AN has more than 1 IP address (e. g. for telnet/SNMP), s= o we have to differentiate here and if one can see the IP addess for a sess= ion in the ancpAnCurrentSessionTable, someone has to configure it somewhere= , right? = >>>[MF] >>> >>>regards, >>>Stefaan >>> >>> >>> >>> >>> >>>>I'll be glad to hear more opinions on those issues. >>>> >>>>Regards, >>>>Moti >>>> >>>> >>>>-----Original Message----- >>>>From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = >>>>Of Stefaan DE CNODDER >>>>Sent: Friday, February 15, 2008 11:45 AM >>>>To: Freudenberger, Markus >>>>Cc: Haag, T; Busser,M; ancp@ietf.org >>>>Subject: Re: [ANCP] missing items in the ancp-mib draft >>>> >>>> >>>>Hi Markus, >>>> >>>>The parameters related to control channel has been intentionally not = >>>>been included in the ANCP MIB because these attributes are to be = >>>>configured in other MIBs. For instance, if the VLAN on which ANCP is = >>>>running needs p-bit 5, then that is to be configured in the = >>>>corresponding ethernet MIB where VLANs are configured. The same for >>>>PVCs: I guess there are ATM MIBs where the attributes of all the PVCs = >>>>can be configured. >>>> >>>>Then you also need the selection of the VLAN or PVC to be used for ANCP= . = >>>>Actually, ANCP are IP packets originated from an IP address in the = >>>>AN, and transmitted like any other IP packet, i.e., the AN performs = >>>>an IP lookup in its routing table. So if the correct routing cannot = >>>>be achieved because the IP address of the directly attached interface = >>>>of the "ANCP VLAN" is not used as NAS address, then an appriopriate = >>>>route has to be configured such that these packets are going to the = >>>>VLAN on which they should be. However, also this "routing = >>>>information" (in whatever form) is to be configured in other MIBs than = the ANCP MIB. >>>> >>>>Look it like this in case of ethernet: if the AN generates an ANCP = >>>>message to the NAS, then the ANCP message is put in an ethernet = >>>>frame, this ethernet frame needs a MAC destination address. To get = >>>>the MAC destination address, the AN has to send an ARP to an IP = >>>>address. This IP address is the next-hop IP address, which it gets = >>> >>>>from the routing information. It can be a next-hop of a route, or in = >>> >>>>case the NAS IP address is directly attached, the IP packet matches the= direct route. >>>> >>>>So I have the feeling that this "routing information" for ANCP can = >>>>exist in multiple forms: >>>>(1) a route with next-hop, or directly attached >>>>(2) a VLAN (so no next-hop and then the NAS IP must be directly = >>>>attached for sending an ARP). >>>>- ... >>>> >>>>So I have the feeling that this just do not belong to an ANCP MIB. = >>>>For sure option (1) should not be in the ANCP MIB, (2) could be added = >>>>but since a generic solution anyhow requires (1), I do not see the = >>>>need to add something in the ANCP MIB. >>>> >>>>Extra filters in the ANCP MIB could be added like for instance that = >>>>ANCP messages may only be sent or received on particular VLANs, but = >>>>that is just an extra ACL, and each implementation can add as much = >>>>security as needed and this should maybe not be in a standard ANCP MIB. >>>> >>>>Do you agree with this? >>>> >>>>Thanks for the review, all comments are very welcome. >>>> >>>>regards, >>>>Stefaan >>>> >>>> >>>>Freudenberger, Markus wrote: >>>> >>>> >>>> >>>> >>>>>Hi all, >>>>> >>>>>looking into the actual ancp-mib draft, I am misssing the following: >>>>> >>>>>1) the possibilty to configure the IP address on the AN for the contro= l channel as it is already defined for the peer NAS. This implies adding ad= ditional entries into the ancpAnCurrentSessionTable for reading the control= channel ip address of the NAS. >>>>> >>>>>2) the possibility to configure the allocation of control channel(s) t= o a physical interface with VPI/VCI resp. C-/S-VAN-ID values and Qos/CoS se= tting. = >>>>> >>>>>Both is required to allow the EMS the setup of the control channel wit= h SNMP and this is described in Section 6 of the ancp framework document an= yway (See below). = >>>>> >>>>>----------------------- snip from draft-ietf-ancp-framework-04.txt >>>>>----------------------- 6. Management Related Requirements >>>>> >>>>>o It must be possible to configure the following parameters on the >>>>> Access Node and the NAS: >>>>> >>>>> * Parameters related to the Control Channel transport method: >>>>> these include the VPI/VCI and transport characteristics (e.g. >>>>> VBR-rt or CBR) for ATM networks or the C-VLAN ID and S-VLAN ID >>>>> and p-bit marking for Ethernet networks; >>>>> >>>>> * Parameters related to the Control Channel itself: these include >>>>> the IP address of the IP interface on the Access Node and the >>>>> NAS >>>>>----------------------- snip from draft-ietf-ancp-framework-04.txt >>>>>----------------------- >>>>> >>>>>Any comments? >>>>> >>>>>Regards >>>>>Markus Freudenberger >>>>> >>>>>T-Systems Enterprise Services GmbH >>>>>Systems Integration >>>>>Telco Project & Design >>>>>Line of Business Networks & Processes Technology Consultant = >>>>>Deutsche-Telekom-Allee 7, D-64295 Darmstadt >>>>>+49 6151 937-3679 (Phone) >>>>>+49 6151 937-19875 (Fax) >>>>>+49 521 5224 5816 (PC-Fax) >>>>>E-Mail: mailto:markus.freudenberger@t-systems.com >>>>>Internet: http://t-systems.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>T-Systems Enterprise Services GmbH >>>>>>Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: = >>>>>>Reinhard Clemens (Vorsitzender)*, Helmut Binder, Albert Henn, Olaf = >>>>>>Heyden*, Katrin Horstmann, Wilfried Peters*, Dr. Herbert Schaaff*, = >>>>>>Zvezdana Seeger* >>>>>>Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der >>>>>>Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 = >>>>>>*Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG >>>>>> >>>>> >>>>>Notice: This transmittal and/or attachments may be privileged or confi= dential. If you are not the intended recipient, you are hereby notified tha= t you have received this transmittal in error; any review, dissemination, o= r copying is strictly prohibited. If you received this transmittal in error= , please notify us immediately by reply and immediately delete this message= and all its attachments. Thank you. >>>>>T-Systems - Business flexibility >>>>> >>>>> >>>>>_______________________________________________ >>>>>ANCP mailing list >>>>>ANCP@ietf.org >>>>>http://www.ietf.org/mailman/listinfo/ancp >>>> >>>>_______________________________________________ >>>>ANCP mailing list >>>>ANCP@ietf.org >>>>http://www.ietf.org/mailman/listinfo/ancp >>> >>> >>_______________________________________________ >>ANCP mailing list >>ANCP@ietf.org >>http://www.ietf.org/mailman/listinfo/ancp > = > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > http://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Feb 21 07:15:56 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2315128CA82; Thu, 21 Feb 2008 07:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_39=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kp64G3pqo7m3; Thu, 21 Feb 2008 07:15:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81D4A28CA20; Thu, 21 Feb 2008 07:15:53 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B26128CA75 for ; Thu, 21 Feb 2008 07:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVDslkGDRMFZ for ; Thu, 21 Feb 2008 07:15:49 -0800 (PST) Received: from eci-iron1.ecitele.com (eci-iron1.ecitele.com [147.234.242.117]) by core3.amsl.com (Postfix) with ESMTP id 008CA28CA16 for ; Thu, 21 Feb 2008 07:15:47 -0800 (PST) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 21 Feb 2008 17:44:04 +0200 Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Feb 2008 17:15:43 +0200 Received: from ILPTMAIL01.ecitele.com (147.234.245.210) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server id 8.1.240.5; Thu, 21 Feb 2008 17:15:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 17:15:40 +0200 Message-ID: <83153A1EB675AF4F82E134FA27F95F6702FE934A@ilptex01.ecitele.com> In-Reply-To: <47BD83E7.4040009@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] missing items in the ancp-mib draft Thread-Index: Ach0kic9ChAkuZD1RwyrFeZGgpMMFwAAWTAg References: <1B6169C658325341A3B8066E23919E1C81F76F@S4DE8PSAANK.mitte.t-com.de><47B55F0E.7040205@alcatel-lucent.be><83153A1EB675AF4F82E134FA27F95F6702F354FA@ilptex01.ecitele.com><47B94869.8030905@alcatel-lucent.be><1B6169C658325341A3B8066E23919E1C81F782@S4DE8PSAANK.mitte.t-com.de><47BAE191.5040406@alcatel-lucent.be><1B6169C658325341A3B8066E23919E1C81F785@S4DE8PSAANK.mitte.t-com.de> <47BC2A44.4050104@alcatel-lucent.be> <83153A1EB675AF4F82E134FA27F95F6702F9C8D0@ilptex01.ecitele.com> <1B6169C658325341A3B8066E23919E1C81F78C@S4DE8PSAANK.mitte.t-com.de> <83153A1EB675AF4F82E134FA27F95F6702F9CA89@ilptex01.ecitele.com> <47BD83E7.4040009@alcatel-lucent.be> From: Moti Morgenstern To: "Stefaan DE CNODDER" X-OriginalArrivalTime: 21 Feb 2008 15:15:43.0590 (UTC) FILETIME=[A0768060:01C8749C] Cc: "Haag, T" , "Busser, M" , ancp@ietf.org, "Freudenberger, Markus" Subject: Re: [ANCP] missing items in the ancp-mib draft X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi again, The relationships are more like this: The bridge port, on one hand, is configured either over an ifIndex or over = a more complicated entity. That's the role of dot1dBasePortIfIndex and dot1= dBasePortCircuit, respectivly, to indicate. A bridge port, on the other hand, can be a member in one or more VLANs. Man= y times, but not always, there will be other bridge ports in the VLAN's "Me= mbers List". When that happens, I assume there's a need to employ spanning = tree protocol. If you specify a classifier for ANCP flow based on VLAN ID (or IDs) then I = believe it is associated with all NI bridge ports that are members in that = VLAN(s). Regards, Moti -----Original Message----- From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] = Sent: Thursday, February 21, 2008 4:00 PM To: Moti Morgenstern Cc: Freudenberger, Markus; Haag, T; Busser, M; ancp@ietf.org Subject: Re: [ANCP] missing items in the ancp-mib draft Hi, I also think it is a good idea to refer to an interface in an existing = MIB like the bridge MIB, but ANCP runs on a VLAN and not an a bridge = port. A VLAN can be configured on multiple ports, so what is in this = case the bridge port? Does it mean that when ANCP has to run over S/C = VLAN 100/200, then S/C VLAN 100/200 gets a unique bridge port number to = be used for dot1dBasePort and then dot1dBasePortCircuit gets the value = 100 200 ? Is that how it works? If that's the case, then it looks very = good. regards, Stefaan Moti Morgenstern wrote: > Hi, > = > Regarding to "how to address the underlying entity", I think that we have= two objects in dot1dBasePortTable that provide the link to the underlying = entity. > = > In case the underlying entity is addressable by a unique ifIndex value th= en dot1dBasePortIfIndex is enough. If that is not the case (e.g., a PVC is = addressed also by VPI and VCI and there might be multiple PVCs per ifIndex)= then dot1dBasePortCircuit can be used. = > = > Anyway, I believe attaching the ANCP flow to a bridge port and not direct= ly to the lower layer is more "elegant". > = > Regards, Moti > -----Original Message----- > From: Freudenberger, Markus [mailto:Markus.Freudenberger@t-systems.com] = > Sent: Wednesday, February 20, 2008 6:05 PM > To: Moti Morgenstern; stefaan.de_cnodder@alcatel-lucent.be > Cc: Haag, T; Busser, M; ancp@ietf.org > Subject: AW: [ANCP] missing items in the ancp-mib draft > = > All, > = > Stefaan, you are right, but what we still need in the ANCP-MIB is the ass= ociation between the session and the layer 2 transport medium (ATM/VLAN) to= gether with the physical interface. > Moti's proposal would possibly allow that but we may need to determine if= the bridge-mib really achieves all requirements. > = > Assuming Moti thinks about the dot1dBasePortTable (1.3.6.1.2.1.17.1.4) fr= om the BRIDGE-MIB, there should also be described, how to address the under= laying entity, e.g. ATM-PVC, and its parameters. = > = > Regards > Markus > = > = > -----Urspr=FCngliche Nachricht----- > Von: Moti Morgenstern [mailto:Moti.Morgenstern@ecitele.com] = > Gesendet: Mittwoch, 20. Februar 2008 16:05 > An: Stefaan DE CNODDER; Freudenberger, Markus > Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org > Betreff: RE: [ANCP] missing items in the ancp-mib draft > = > Hi Markus & Stefaan, > = > I think that it is more correct to associate the ANCP session with a brid= ge port identifier. This is cleaner because then the IETF bridge MIB provid= es the information regarding to the underlaying entity, which can perfectly= be ATM PVC. > = > Regards, Moti > = > = > -----Original Message----- > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of S= tefaan DE CNODDER > Sent: Wednesday, February 20, 2008 3:25 PM > To: Freudenberger, Markus > Cc: Haag, T; Busser,M; ancp@ietf.org > Subject: Re: [ANCP] missing items in the ancp-mib draft > = > = > Markus, > = > Thinking further about this: S/C VLAN, p-bit, VPI/VCI can be added to the= cofiguration per session, but not the QoS class for VPI/VCI. = > Because if a PVC is used for 10 ANCP sessions, then it cannot be that one= session uses this PVC as UBR and another session as CBR. Also CBR require= s extra parameters like a bandwidth, and VBR even requires more like leaky = bucket sizes, ... This all looks very specific ATM configuration not to be= part of the ANCP MIB. > = > So it is Ok for you to add the following objects to the configuration of = a session: > = > S-VLAN > C-VLAN > p-bits > VPI > VCI > = > Without QoS > = > regards, > Stefaan > = > = > Freudenberger, Markus wrote: > = > = >>Hi Stefaan, >> >>the ancp session runs in the subnet as the configured VLAN. >> >>Example configuration: = >> >> AN NAS >>----------------------------------- >>Bridge-port 1 1 >>S-VLAN-ID 10 10 >>C-VLAN-ID 10 10 >>prio 7 7 >>VPI 32 32 = >>VCI 32 32 >>QoS CBR CBR >>IP-address 192.168.0.1/30 192.168.0.2/30 >>... >> >>regards >>Markus = >> >> >>-----Urspr=FCngliche Nachricht----- >>Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] >>Gesendet: Dienstag, 19. Februar 2008 15:03 >>An: Freudenberger, Markus >>Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org >>Betreff: Re: [ANCP] missing items in the ancp-mib draft >> >> >>Hi Markus, >> >>Indeed, ANCP is just one application that uses IP, and as soon the ANCP p= acket is encapsulated into an IP packet, it goes to the IP layer where it i= s treated like any other IP packet. >> >>Suppose in ancpAnSessionConfigTable, an attribute VLAN is added, and I co= nfigure this VLAN equal to 100. Ok, the AN can sent then the ANCP packet t= o VLAN 100 (even though the IP routing table says that the best path to the= NAS IP address is via another VLAN), then my question is: = >>what will be the MAC destination address of this IP packet, i.e., to whic= h IP address has the AN to send an ARP request to learn the MAC destination= address to be used for the ANCP packet? Knowing the VLAN ID is just not s= ufficient according to me. Either the NAS IP address MUST be in the subnet= as the configured VLAN (in which case the ARP is directly to the NAS IP ad= dress), or an IP lookup is done that results in a next-hop with correspondi= ng outgoing interface (=3DVLAN, PVC, ...). In the latter case, no VLAN is = needed in ancpAnSessionConfigTable because the IP lookup will automatically= give the VLAN. >> >>For me both options are Ok, I just want to know how it has to work. >> >>regards, >>Stefaan >> >> >>Freudenberger, Markus wrote: >> >> >> >>>Moti, Stefaan, >>> >>>I agree with Moti's comments. = >>>See my further comments to Stefaans statemtens inline, marked with "[MF]= ". >>> >>>Are there views from other people? >>> >>>regards >>>Markus >>> >>>-----Urspr=FCngliche Nachricht----- >>>Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] >>>Gesendet: Montag, 18. Februar 2008 09:57 >>>An: Moti Morgenstern; Freudenberger, Markus >>>Cc: Haag, Thomas; Busser, Michael; ancp@ietf.org >>>Betreff: Re: [ANCP] missing items in the ancp-mib draft >>> >>> >>>Moti, Markus, >>> >>>Moti Morgenstern wrote: >>> >>> >>> >>> >>>>Hi, >>>> >>>>I think what Markus wrote is pretty correct. There should be, for examp= le, a MIB for associating ANCP session with "ANCP VLAN". So, if that MIB is= already available, in already existing RFCs, then the ANCP MIB should incl= ude a section describing that as part of the "Relationship to Other MIB Mod= ules", as done with the interfaces MIB. That will allow software engineers = (even if not members in our honorable ANCP WG) to see the whole picture. Ho= wever, if such a MIB is not available, then obviously the ANCP MIB should d= escribe what is the gap and define the MIB for filling it. = >>>> >>>>More specifically (and please correct me if I'm wrong): >>>>- I do not recall a MIB for ATM PVCs that assumes single VC with multip= lexed services. However, in this case I think that we do not need such a MI= B because the ANCP control channel should actually be associated with bridg= e port (and that bridge port has a MIB that provides the information on the= underlying L2). The question is how does the EMS associate the ANCP contro= l channel with a specific bridge port? >>> >>> >>>An informational text can be added to explain how IP/ANCP packets are to= be routed but there is no formal linking with any other MIB. How the IP l= ayer is configured is independent from how the protocol is configured. >>> >>>[MF] >>>Stefaan, do you mean it is independent because ANCP is one of many other= applications which uses IP? If yes, you are right but the IP layer is esse= ntial for ANCP (as the architecture chooses TCP/IP as a tranpsort medium) a= nd as a consequence it is also essential to configure it and associate it w= ith a certain ANCP session from an EMS. This has to be mentioned somehow in= the document. I don't see a problem to create a reference to an RFC and/or= a MIB which provides these capabilities. But it is still needed to define= the link between the IP layer and ANCP session. >>>[MF] >>> >>> >>>For me it is also fine that ANCP packets are not routed in the AN but th= at ANCP is bound to a certain interface (=3DVLAN or PVC) like it is for ins= tance with OSPF. But then the configured NAS IP address in the AN must be = a directly attached IP address, if the NAS IP address is not directly attac= hed, then the AN does not know which IP address to ARP (which it normally g= ets from the next-hop of the matching route). >>> >>>When ANCP bypasses routing, VLAN-ID or PVC (with some extra attributes o= nly specific for ANCP packets like for instance p-bits) could be configured= in ancpAnSessionConfigTable. >>> >>>For me both options are fine, but if the second option is selected, the = the framework draft should also mention this limitation (which should not b= e a problem if we all agree I suspect). >>> >>>[MF] >>>Sorry but I cannot indicate the options. Which limitation do you mean? = >>>Anyway, I think the ANCP packets are not routed in the AN, they are term= inated and the next IP hop is the NAS. The ancp framework document states f= or this purpose: >>>... >>> o Control Channel: a bidirectional IP communication interface >>> between the controller function (in the NAS) and the reporting/ >>> enforcement function (in the AN). It is assumed that this >>> interface is configured (rather than discovered) on the AN and the >>> NAS. >>>... >>>and >>>... >>> o The Control Channel MUST be terminated at the Access Node. >>>... >>> >>>To summarize, I only see the option to add additional attributes into th= e ancpAnSessionConfigTable for layer 2 connection parameters (VLAN, VCC, Qo= S class, priority) per session. = >>>[MF] >>> >>>What is your preference? >>> >>> >>> >>> >>> >>>>- Stefaan says that "ANCP are IP packets originated from an IP address = in the AN" and that's correct. But how does the EMS configure that address?= How does the EMS associate it with one of possibly multiple sessions? >>>> >>> >>> >>>It is the IP routing table that associates an ANCP packet (IP packet) to= a certain outgoing interface. The AN IP address is not configured per ses= sion but you can see the selected IP address in ancpAnCurrentSessionTable. = Typically, when a device generates an IP packet, its IP source address is = usually set to the IP address of the outgoing IP interface. When the AN on= ly has 1 IP address (after all it is not a router), then it is straitforwar= d. >>> >>>[MF] >>>I disagree, the AN has more than 1 IP address (e. g. for telnet/SNMP), s= o we have to differentiate here and if one can see the IP addess for a sess= ion in the ancpAnCurrentSessionTable, someone has to configure it somewhere= , right? = >>>[MF] >>> >>>regards, >>>Stefaan >>> >>> >>> >>> >>> >>>>I'll be glad to hear more opinions on those issues. >>>> >>>>Regards, >>>>Moti >>>> >>>> >>>>-----Original Message----- >>>>From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = >>>>Of Stefaan DE CNODDER >>>>Sent: Friday, February 15, 2008 11:45 AM >>>>To: Freudenberger, Markus >>>>Cc: Haag, T; Busser,M; ancp@ietf.org >>>>Subject: Re: [ANCP] missing items in the ancp-mib draft >>>> >>>> >>>>Hi Markus, >>>> >>>>The parameters related to control channel has been intentionally not = >>>>been included in the ANCP MIB because these attributes are to be = >>>>configured in other MIBs. For instance, if the VLAN on which ANCP is = >>>>running needs p-bit 5, then that is to be configured in the = >>>>corresponding ethernet MIB where VLANs are configured. The same for >>>>PVCs: I guess there are ATM MIBs where the attributes of all the PVCs = >>>>can be configured. >>>> >>>>Then you also need the selection of the VLAN or PVC to be used for ANCP= . = >>>>Actually, ANCP are IP packets originated from an IP address in the = >>>>AN, and transmitted like any other IP packet, i.e., the AN performs = >>>>an IP lookup in its routing table. So if the correct routing cannot = >>>>be achieved because the IP address of the directly attached interface = >>>>of the "ANCP VLAN" is not used as NAS address, then an appriopriate = >>>>route has to be configured such that these packets are going to the = >>>>VLAN on which they should be. However, also this "routing = >>>>information" (in whatever form) is to be configured in other MIBs than = the ANCP MIB. >>>> >>>>Look it like this in case of ethernet: if the AN generates an ANCP = >>>>message to the NAS, then the ANCP message is put in an ethernet = >>>>frame, this ethernet frame needs a MAC destination address. To get = >>>>the MAC destination address, the AN has to send an ARP to an IP = >>>>address. This IP address is the next-hop IP address, which it gets = >>> >>>>from the routing information. It can be a next-hop of a route, or in = >>> >>>>case the NAS IP address is directly attached, the IP packet matches the= direct route. >>>> >>>>So I have the feeling that this "routing information" for ANCP can = >>>>exist in multiple forms: >>>>(1) a route with next-hop, or directly attached >>>>(2) a VLAN (so no next-hop and then the NAS IP must be directly = >>>>attached for sending an ARP). >>>>- ... >>>> >>>>So I have the feeling that this just do not belong to an ANCP MIB. = >>>>For sure option (1) should not be in the ANCP MIB, (2) could be added = >>>>but since a generic solution anyhow requires (1), I do not see the = >>>>need to add something in the ANCP MIB. >>>> >>>>Extra filters in the ANCP MIB could be added like for instance that = >>>>ANCP messages may only be sent or received on particular VLANs, but = >>>>that is just an extra ACL, and each implementation can add as much = >>>>security as needed and this should maybe not be in a standard ANCP MIB. >>>> >>>>Do you agree with this? >>>> >>>>Thanks for the review, all comments are very welcome. >>>> >>>>regards, >>>>Stefaan >>>> >>>> >>>>Freudenberger, Markus wrote: >>>> >>>> >>>> >>>> >>>>>Hi all, >>>>> >>>>>looking into the actual ancp-mib draft, I am misssing the following: >>>>> >>>>>1) the possibilty to configure the IP address on the AN for the contro= l channel as it is already defined for the peer NAS. This implies adding ad= ditional entries into the ancpAnCurrentSessionTable for reading the control= channel ip address of the NAS. >>>>> >>>>>2) the possibility to configure the allocation of control channel(s) t= o a physical interface with VPI/VCI resp. C-/S-VAN-ID values and Qos/CoS se= tting. = >>>>> >>>>>Both is required to allow the EMS the setup of the control channel wit= h SNMP and this is described in Section 6 of the ancp framework document an= yway (See below). = >>>>> >>>>>----------------------- snip from draft-ietf-ancp-framework-04.txt >>>>>----------------------- 6. Management Related Requirements >>>>> >>>>>o It must be possible to configure the following parameters on the >>>>> Access Node and the NAS: >>>>> >>>>> * Parameters related to the Control Channel transport method: >>>>> these include the VPI/VCI and transport characteristics (e.g. >>>>> VBR-rt or CBR) for ATM networks or the C-VLAN ID and S-VLAN ID >>>>> and p-bit marking for Ethernet networks; >>>>> >>>>> * Parameters related to the Control Channel itself: these include >>>>> the IP address of the IP interface on the Access Node and the >>>>> NAS >>>>>----------------------- snip from draft-ietf-ancp-framework-04.txt >>>>>----------------------- >>>>> >>>>>Any comments? >>>>> >>>>>Regards >>>>>Markus Freudenberger >>>>> >>>>>T-Systems Enterprise Services GmbH >>>>>Systems Integration >>>>>Telco Project & Design >>>>>Line of Business Networks & Processes Technology Consultant = >>>>>Deutsche-Telekom-Allee 7, D-64295 Darmstadt >>>>>+49 6151 937-3679 (Phone) >>>>>+49 6151 937-19875 (Fax) >>>>>+49 521 5224 5816 (PC-Fax) >>>>>E-Mail: mailto:markus.freudenberger@t-systems.com >>>>>Internet: http://t-systems.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>T-Systems Enterprise Services GmbH >>>>>>Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: = >>>>>>Reinhard Clemens (Vorsitzender)*, Helmut Binder, Albert Henn, Olaf = >>>>>>Heyden*, Katrin Horstmann, Wilfried Peters*, Dr. Herbert Schaaff*, = >>>>>>Zvezdana Seeger* >>>>>>Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der >>>>>>Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 = >>>>>>*Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG >>>>>> >>>>> >>>>>Notice: This transmittal and/or attachments may be privileged or confi= dential. If you are not the intended recipient, you are hereby notified tha= t you have received this transmittal in error; any review, dissemination, o= r copying is strictly prohibited. If you received this transmittal in error= , please notify us immediately by reply and immediately delete this message= and all its attachments. Thank you. >>>>>T-Systems - Business flexibility >>>>> >>>>> >>>>>_______________________________________________ >>>>>ANCP mailing list >>>>>ANCP@ietf.org >>>>>http://www.ietf.org/mailman/listinfo/ancp >>>> >>>>_______________________________________________ >>>>ANCP mailing list >>>>ANCP@ietf.org >>>>http://www.ietf.org/mailman/listinfo/ancp >>> >>> >>_______________________________________________ >>ANCP mailing list >>ANCP@ietf.org >>http://www.ietf.org/mailman/listinfo/ancp > = > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > http://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Feb 22 08:00:05 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9B1528C25E; Fri, 22 Feb 2008 08:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOED32VECHIR; Fri, 22 Feb 2008 08:00:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D5193A6C47; Fri, 22 Feb 2008 08:00:03 -0800 (PST) X-Original-To: ancp@ietf.org Delivered-To: ancp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CEB173A6C47; Fri, 22 Feb 2008 08:00:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080222160001.CEB173A6C47@core3.amsl.com> Date: Fri, 22 Feb 2008 08:00:01 -0800 (PST) Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-framework-05.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks Author(s) : S. Ooghe, et al. Filename : draft-ietf-ancp-framework-05.txt Pages : 46 Date : 2008-02-22 The purpose of this document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform QoS-related, service-related and Subscriber-related operations. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather using a direct device-device communication. This allows for performing access link related operations within those network elements, while avoiding impact on the existing OSS systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ancp-framework-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ancp-framework-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-22074823.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ancp-framework-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ancp-framework-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-22074823.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp --NextPart-- From ancp-bounces@ietf.org Tue Feb 26 06:48:09 2008 Return-Path: X-Original-To: ietfarch-ancp-archive@core3.amsl.com Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99C7B28C32E; Tue, 26 Feb 2008 06:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.794 X-Spam-Level: X-Spam-Status: No, score=0.794 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGEuz9Hv2DJ2; Tue, 26 Feb 2008 06:48:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4EA3A690C; Tue, 26 Feb 2008 06:48:06 -0800 (PST) X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 424483A690C for ; Tue, 26 Feb 2008 06:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjatg7NtpIuf for ; Tue, 26 Feb 2008 06:48:02 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 7A77B3A6885 for ; Tue, 26 Feb 2008 06:48:02 -0800 (PST) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.ad2.ad.alcatel.com [155.132.6.75]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m1QEYUl3029216 for ; Tue, 26 Feb 2008 15:34:30 +0100 Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.32]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 26 Feb 2008 15:47:53 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 15:47:51 +0100 Message-ID: <0458D2EE0C36744BABB36BE37805C29A01835E7F@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Philly agenda Thread-index: Ach4hpALDIfxhsJtSBCrFimcHAlLDw== From: "BOCCI Matthew" To: X-OriginalArrivalTime: 26 Feb 2008 14:47:53.0048 (UTC) FILETIME=[90CEC580:01C87886] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: [ANCP] Draft Philly agenda X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 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="===============0213480470==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0213480470== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87886.9099D01C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87886.9099D01C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please find attached the draft agenda for Philadelphia. Please let me know if you have any comments. Thanks Matthew TUESDAY, March 4th, 2008 - 17:40 - 19:50 ----------------------------------------- CHAIRS: Wojciech Dec & Matthew Bocci 10 mins WG Status and Update - Chairs 10 mins - Vendor Specific Message for ANCP - Peter Arberg (parberg@redback.com) http://tools.ietf.org/id/draft-arberg-ancp-vendorspecific-00.txt 10 mins - ANCP Framework and Requirements - Stefaan de Cnodder (stefaan.de_cnodder@alcatel-lucent.be) http://tools.ietf.org/html/draft-ietf-ancp-framework-05 10 mins - ANCP NAS and AN MIBs - Stefaan de Cnodder (stefaan.de_cnodder@alcatel-lucent.be) http://tools.ietf.org/id/draft-decnodder-ancp-mib-nas-00.txt http://tools.ietf.org/html/draft-ietf-ancp-mib-an-02 30 mins - ANCP Protocol Design Team Update - Philippe Champagne, Roberta Maglione, Stefaan DeCnodder, Sanjay Wadhwa ------_=_NextPart_001_01C87886.9099D01C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft Philly agenda

Please find attached the draft agenda = for Philadelphia.

Please let me know if you have any = comments.

Thanks

Matthew

TUESDAY, March 4th, 2008 – = 17:40 – 19:50
-----------------------------------------
CHAIRS: Wojciech Dec & = Matthew Bocci

10 mins WG Status and Update - = Chairs

10 mins - Vendor Specific Message = for ANCP – Peter Arberg (parberg@redback.com)
http://tools.ietf.org/id/draft-arberg-ancp-vendorspecific-00.txt

10 mins – ANCP Framework = and Requirements – Stefaan de Cnodder = (stefaan.de_cnodder@alcatel-lucent.be)
http://tools.ietf.org/html/draft-ietf-ancp-framework-05

10 mins – ANCP NAS and AN = MIBs – Stefaan de Cnodder = (stefaan.de_cnodder@alcatel-lucent.be)
= http://tools.ietf.org/id/draft-decnodder-ancp-mib-nas-00.txt<= /U>
http://tools.ietf.org/html/draft-ietf-ancp-mib-an-02

30 mins – ANCP Protocol = Design Team Update – Philippe Champagne, Roberta Maglione, Stefaan = DeCnodder, Sanjay Wadhwa




------_=_NextPart_001_01C87886.9099D01C-- --===============0213480470== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org http://www.ietf.org/mailman/listinfo/ancp --===============0213480470==--