[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ANCP] missing items in the ancp-mib draft
Hi Markus,
Ok, lets add a reference to both L2 and L3 interface in the ANCP session configuration. I am not really convinced this is the right approach, but lets take it if nobody else see problems.
For the NAS, there is no per ANCP session configuration. See section 5.1 of the protocol draft:
ANCP will use TCP for exchanging protocol messages. [5] defines the
GSMP message encapsulation for TCP. The TCP session is initiated
from the DSLAM (access node) to the NAS (controller). This is
necessary to avoid static provisioning on the NAS for all the DSLAMs
that are being served by the NAS. It is easier to configure a given
DSLAM with the single IP address of the NAS that serves the DSLAM.
This is a deviation from [5] which indicates that the controller
initiates the TCP connection to the switch.
NAS listens for incoming connections from the access nodes. Port 6068
is used for TCP connection.
So if AN1 uses S/C VLAN 100/1 and AN2 uses S/C VLAN 100/2 and you also want to configure this in the NAS, then it means that there is per ANCP session configuration in the NAS which is not in line with the text above. Maybe just an IP interface is possible because I expect that in this example VLAN 100/1 and 100/2 are under the same IP interface.
Since there is no session configuration on the NAS, the NAS just listens on port 6068 and wait until it receives something. When a TCP session is setup using this port, the NAS automatically knows the S/C VLAN.
Currently in the NAS MIB I have a configuration per partition because after all, the NAS needs some configuration parameters to know some timer values, etc to be used for the ANCP sessions. Not sure this is a good approach, maybe just scalars are also good.
regards,
Stefaan
-----Original Message-----
From: Freudenberger, Markus [mailto:Markus.Freudenberger at t-systems.com]
Sent: vrijdag 28 maart 2008 9:45
To: DE CNODDER Stefaan; ancp at ietf.org; Moti.Morgenstern at ecitele.com
Cc: Haag, T; Busser, M
Subject: AW: [ANCP] missing items in the ancp-mib draft
Hello Stefaan,
One more commment inline.
Regards
Markus
-----Ursprüngliche Nachricht-----
Von: DE CNODDER Stefaan [mailto:stefaan.de_cnodder at alcatel-lucent.be]
Gesendet: Freitag, 21. März 2008 11:09
An: Freudenberger, Markus; ancp at ietf.org; Moti.Morgenstern at ecitele.com
Cc: Haag, Thomas; Busser, Michael
Betreff: RE: [ANCP] missing items in the ancp-mib draft
Hi Markus,
See inline
2 solutions are possible, in any case, both solutions will result in adding objects to table where ANCP sessions are configured (ancpAnSessionConfigTable).
Solution 1:
configure for ATM the values of ifindex, PVI and VCI per session. These 3 values are referring to a standard ATM MIB where the PVC characteristics are configured (ATM QoS class, sustained cell rate, ...). For Ethernet, this looks less clear because I could not find a standard MIB that supports VLAN stacking, and putting this in the ANCP MIB is really the wrong place. In any case, for ethernet objects could be added to indicate S-VLAN ID, C-VLAN ID and p-bits without referring to any other standard MIB.
Solution 2 (comment from Woj during the meeting):
ANCP is not to be bound to a VLAN or PVC, but ANCP has to be bound to an IP interface, whather there in underneath this IP interface. After all, ANCP is an IP protocol. To support this, the table can be extended with a single object: ifindex. This ifindex can in principle refer to any interface, but in this case it has to be an IP interface. What is under this IP interface (VLANs, PVC, ...), is not to be defined in the ANCP MIB. Not sure what has to be done for p-bit values in this case because this looks to be part of the ANCP MIB and is not part of the VLAN configuration.
Note that the requirements above from the framework are requirements for ANs and NASses but they are not requirements for the ANCP MIB, i.e., some of the required configuration is not in the ANCP MIB.
[MF] From my point of view, the intention should be to reflect all required configurations from the framework document in the ANCP-AN-MIB and/or in the ANCP-NAS-MIB if applicable as after all, the ANCP framwork document serves as a normative reference in the MIB draft documents.
I, personally, have not really a preference of the 2 solutions above but I feel more confortable with solution 1.
[MF] I also prefer solution 1. But to complete the picture, an addtional attribute should be added into in the ANCP-AN-MIB to configure the IP address of the AN resp. into in the ANCP-NAS-MIB to configure the IP address at the NAS.
[Stefaan] If the VPI/VCI is configured then this PVC can only be used by ANCP if there is also an IP interface configured on this PVC so the IP address follows implicit from the PVC or VLAN configuration. At least when the IP source address to be used is always the IP address of the outgoing IP interface. The configuration of the interface stack is not part of ANCP, and the 2 solutions above is simply to which layer in the interface stack the ANCP MIB is referring to: to layer 2 (solution 1) or to layer 3 (solution 2). If besides the PVC or VLAN, also the IP address is added, it looks to me that this is using solution 1 and 2 at the same time, and looks somehow too much to me.
[MF, 08/03/28] Let's use the approach from Moti: Adding a an object into the ANCP session table which refers to the atmVclTable (ATM case). For the Ethernet case I think the q-/p-bridge-mib provides the needed capabilities, a refering object should be added into the ANCP session table as well.
For IP address assingment I propose to add reference to the ipAddressTable (RFC4293) which contains a pointer the ifindex. In combination with the if-/ifstacktable it should meet all requirmerents from the ANCP architecture.
Should the NAS MIB also have such attributes? I do not think so because it is the AN that sets up the transport session, and the NAS will see on which interface the ANCP packets are arrived.
[MF] I think the NAS needs such attributes as well. Otherwise, how should the NAS associate the incoming ANCP packets to a particular session (Assuming that N sessions are terminated at one NAS)? Any view from other people?
[Stefaan] There is no per-session configuration in the NAS (to avoid that the NAS needs extra configuration for each AN installed - as described in the protocol draft). The NAS will receive the messages from a particular PVC/VLAN, and ANCP session configuration is done currently in the NAS MIB based on the partition ID but I am not sure if this is the correct method.
regards,
Stefaan
-----Original Message-----
From: Freudenberger, Markus [mailto:Markus.Freudenberger at t-systems.com]
Sent: woensdag 19 maart 2008 14:39
To: ancp at ietf.org; DE CNODDER Stefaan; Moti.Morgenstern at ecitele.com
Cc: Haag, T; Busser, M
Subject: AW: [ANCP] missing items in the ancp-mib draft
Hello Editors,
because I didn't see any further comments on the exploder since Moti's Mail:
Is it agreed to add addtional functionality into the ANCP-MIB Draft document to reflect the requirements from the framework document?
Thanks
Markus
-----Ursprüngliche Nachricht-----
Von: Moti Morgenstern [mailto:Moti.Morgenstern at ecitele.com]
Gesendet: Donnerstag, 21. Februar 2008 16:16
An: Stefaan DE CNODDER
Cc: Freudenberger, Markus; Haag, Thomas; Busser, Michael; ancp at ietf.org
Betreff: RE: [ANCP] missing items in the ancp-mib draft
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 dot1dBasePortCircuit, respectivly, to indicate.
A bridge port, on the other hand, can be a member in one or more VLANs. Many times, but not always, there will be other bridge ports in the VLAN's "Members 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 at alcatel-lucent.be]
Sent: Thursday, February 21, 2008 4:00 PM
To: Moti Morgenstern
Cc: Freudenberger, Markus; Haag, T; Busser, M; ancp at 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 then 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 directly to the lower layer is more "elegant".
>
> Regards, Moti
> -----Original Message-----
> From: Freudenberger, Markus
> [mailto:Markus.Freudenberger at t-systems.com]
> Sent: Wednesday, February 20, 2008 6:05 PM
> To: Moti Morgenstern; stefaan.de_cnodder at alcatel-lucent.be
> Cc: Haag, T; Busser, M; ancp at 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 association between the session and the layer 2 transport medium (ATM/VLAN) together 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) from the BRIDGE-MIB, there should also be described, how to address the underlaying entity, e.g. ATM-PVC, and its parameters.
>
> Regards
> Markus
>
>
> -----Ursprüngliche Nachricht-----
> Von: Moti Morgenstern [mailto:Moti.Morgenstern at ecitele.com]
> Gesendet: Mittwoch, 20. Februar 2008 16:05
> An: Stefaan DE CNODDER; Freudenberger, Markus
> Cc: Haag, Thomas; Busser, Michael; ancp at 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 be ATM PVC.
>
> Regards, Moti
>
>
> -----Original Message-----
> From: ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf
> Of Stefaan DE CNODDER
> Sent: Wednesday, February 20, 2008 3:25 PM
> To: Freudenberger, Markus
> Cc: Haag, T; Busser,M; ancp at 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ü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
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www.ietf.org/mailman/listinfo/ancp