[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ANCP] missing items in the ancp-mib draft
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üngliche Nachricht-----
> Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder at alcatel-lucent.be]
> Gesendet: Dienstag, 19. Februar 2008 15:03
> An: Freudenberger, Markus
> Cc: Haag, Thomas; Busser, Michael; ancp at 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 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 (=VLAN, 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üngliche Nachricht-----
>>Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder at alcatel-lucent.be]
>>Gesendet: Montag, 18. Februar 2008 09:57
>>An: Moti Morgenstern; Freudenberger, Markus
>>Cc: Haag, Thomas; Busser, Michael; ancp at 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 already 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 (even if not members in our honorable ANCP WG) to see the whole picture. However, if such a MIB is not available, then obviously the ANCP MIB should describe 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 multiplexed 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 layer 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 essential 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 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 that ANCP is bound to a certain interface (=VLAN 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).
>>
>>[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 terminated 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 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? 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 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.
>>
>>[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 session 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 at ietf.org [mailto:ancp-bounces at 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 at 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 additional 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 setting.
>>>>
>>>>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 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 at t-systems.com
>>>>Internet: http://t-systems.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>T-Systems Enterprise Services GmbH
>>>>>Aufsichtsrat: René 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äftsführer gem. § 35 GmbHG
>>>>>
>>>>
>>>>Notice: This transmittal and/or attachments may be privileged or confidential. 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 at ietf.org
>>>>http://www.ietf.org/mailman/listinfo/ancp
>>>
>>>_______________________________________________
>>>ANCP mailing list
>>>ANCP at ietf.org
>>>http://www.ietf.org/mailman/listinfo/ancp
>>
>>
> _______________________________________________
> ANCP mailing list
> ANCP at ietf.org
> http://www.ietf.org/mailman/listinfo/ancp
_______________________________________________
ANCP mailing list
ANCP at ietf.org
http://www.ietf.org/mailman/listinfo/ancp