[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
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).
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.
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