Subject: [ANCP] missing items in the ancp-mib draft

From: "Freudenberger, Markus" <[email-masked]>
Date: Fri, 15 Feb 2008 09:52:35 +0100

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:[email-masked] 
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
[email-masked]
http://www.ietf.org/mailman/listinfo/ancp

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Fri, 15 Feb 2008 10:44:46 +0100

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

---

From: "Freudenberger, Markus" <[email-masked]>
Date: Fri, 15 Feb 2008 15:16:32 +0100

Hi Stefaan,

I am sure that other MIBs already provide attributes to meet these requirements but then they must be linked anyhow to the ANCP MIB to provide a complete specification.
So, the minimum is, to state this in the document, e. g. that allocating ANCP channels to Ethernet VLANs/ATM-VC's is configured with "xyz-MIB".
The better approach, I think, is to identify the needed atttributes from already 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 address 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üngliche Nachricht-----
Von: Stefaan DE CNODDER [mailto:[email-masked]] 
Gesendet: Freitag, 15. Februar 2008 10:45
An: Freudenberger, Markus
Cc: Haag, Thomas; Busser, Michael; [email-masked]
Betreff: 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?

regards,
Stefaan

Freudenberger, Markus wrote:
> ----------------------- snip from draft-ietf-ancp-framework-04.txt 
> ----------------------- 6.  Management Related Requirements
> 
>>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

---

From: Moti Morgenstern <[email-masked]>
Date: Sun, 17 Feb 2008 13:56:15 +0200

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?
- 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?

I'll be glad to hear more opinions on those issues.

Regards,
Moti

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefaan DE CNODDER
Sent: Friday, February 15, 2008 11:45 AM
To: Freudenberger, Markus
Cc: Haag, T; Busser,M; [email-masked]
Subject: Re: [ANCP] missing items in the ancp-mib draft

Hi Markus,

Do you agree with this?

regards,
Stefaan

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Mon, 18 Feb 2008 09:57:13 +0100

Moti, Markus,

> - 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…

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…

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

---

From: "Freudenberger, Markus" <[email-masked]>
Date: Tue, 19 Feb 2008 13:50:42 +0100

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:[email-masked]] 
Gesendet: Montag, 18. Februar 2008 09:57
An: Moti Morgenstern; Freudenberger, Markus
Cc: Haag, Thomas; Busser, Michael; [email-masked]
Betreff: Re: [ANCP] missing items in the ancp-mib draft

Moti, Markus,

> - 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…

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…

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

>   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 
> 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?
> 
>>-----------------------

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Tue, 19 Feb 2008 15:02:57 +0100

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

---

From: "Freudenberger, Markus" <[email-masked]>
Date: Tue, 19 Feb 2008 15:53:01 +0100

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:[email-masked]] 
Gesendet: Dienstag, 19. Februar 2008 15:03
An: Freudenberger, Markus
Cc: Haag, Thomas; Busser, Michael; [email-masked]
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.

regards,
Stefaan

Freudenberger, Markus wrote:

>>>Line of Business Networks & Processes Technology Consultant

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Tue, 19 Feb 2008 16:38:28 +0100

Hi Markus,

In that case, the extra attributes are fine for me.

Thanks,
Stefaan

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Wed, 20 Feb 2008 14:25:24 +0100

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

---

From: Moti Morgenstern <[email-masked]>
Date: Wed, 20 Feb 2008 17:04:52 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of Stefaan DE CNODDER
Sent: Wednesday, February 20, 2008 3:25 PM
To: Freudenberger, Markus
Cc: Haag, T; Busser,M; [email-masked]
Subject: Re: [ANCP] missing items in the ancp-mib draft

Markus,

S-VLAN
C-VLAN
p-bits
VPI
VCI

Without QoS

regards,
Stefaan

---

From: "Freudenberger, Markus" <[email-masked]>
Date: Wed, 20 Feb 2008 17:04:54 +0100

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:[email-masked]] 
Gesendet: Mittwoch, 20. Februar 2008 16:05
An: Stefaan DE CNODDER; Freudenberger, Markus
Cc: Haag, Thomas; Busser, Michael; [email-masked]
Betreff: RE: [ANCP] missing items in the ancp-mib draft

Hi Markus & Stefaan,

Regards, Moti

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefaan DE CNODDER
Sent: Wednesday, February 20, 2008 3:25 PM
To: Freudenberger, Markus
Cc: Haag, T; Busser,M; [email-masked]
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:

>>>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.
>>>
>>>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.
>>>

---

From: Moti Morgenstern <[email-masked]>
Date: Thu, 21 Feb 2008 09:08:11 +0200

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:[email-masked]] 
Sent: Wednesday, February 20, 2008 6:05 PM
To: Moti Morgenstern; [email-masked]
Cc: Haag, T; Busser, M; [email-masked]
Subject: AW: [ANCP] missing items in the ancp-mib draft

All,

Regards
Markus

-----Ursprüngliche Nachricht-----
Von: Moti Morgenstern [mailto:[email-masked]] 
Gesendet: Mittwoch, 20. Februar 2008 16:05
An: Stefaan DE CNODDER; Freudenberger, Markus
Cc: Haag, Thomas; Busser, Michael; [email-masked]
Betreff: RE: [ANCP] missing items in the ancp-mib draft

Hi Markus & Stefaan,

Regards, Moti

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefaan DE CNODDER
Sent: Wednesday, February 20, 2008 3:25 PM
To: Freudenberger, Markus
Cc: Haag, T; Busser,M; [email-masked]
Subject: Re: [ANCP] missing items in the ancp-mib draft

Markus,

S-VLAN
C-VLAN
p-bits
VPI
VCI

Without QoS

regards,
Stefaan

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Thu, 21 Feb 2008 15:00:07 +0100

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

---

From: Moti Morgenstern <[email-masked]>
Date: Thu, 21 Feb 2008 17:15:40 +0200

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:[email-masked]] 
Sent: Thursday, February 21, 2008 4:00 PM
To: Moti Morgenstern
Cc: Freudenberger, Markus; Haag, T; Busser, M; [email-masked]
Subject: Re: [ANCP] missing items in the ancp-mib draft

Hi,

regards,
Stefaan