Subject: [ANCP] Some comments on ANCP MIB

From: "bharat_joshi" <[email-masked]>
Date: Fri, 13 Apr 2007 10:48:55 +0530

Hi Stefaan,

     Couple of questions and suggestion on the MIB document: [I am not
sure if this has already been raised before]

* In 'Structure of the MIB Module', I think it would be good if the
three tables can be defined point wise something similar to the way you
have defined groups]

There are three tables defined in this MIB module:

1. ancpAnSessionConfigTable is used to configure ANCP sessions.

2. ancpAnCurrentSessionTable is used to show the operational status of
an ANCP session.

3. Third table name is not there.

* Does all the objects under these tables are mandatory to be
implemented by an Access Node?

* I think second paragraph of section 5.3 can be moved to Security
Consideration.

* In section 5.4, We assumed that for each port, there is only one
corresponding interface in IF-MIB which does not seems to be correct.
There can be multiple interfaces on one port. Also the reference to
DSL-Line does not seem to be correct as it would be the upstream
interface of AN [Interface towards the NAS] where ANCP would be
configured.

* As per RFC 4181, 'ancpNotifications' should be 'ancpAnNotifications'

* When a session is deleted and the corresponding session-id would be
available. Does this mean that the 'get' on object 'ancpAnNextSessionId'
will start returning this available value? It is not completely clear
from the text. It just says that it will be available.

* If there are partitions, there will be one ANCP session corresponding
to each partition. Right?

* In ancpAnSessionConfigAliveTimer, I think we should use ANCP instead
of GSMP in " duration of a GSMP session" -> " duration of a ANCP
session"

* In ancpAnSessionConfigAliveTimer, please provide an example for
default value 100 i.e. add a value of 100 means 100*100 ms.

* In description of object ancpAnSessionConfigGsmpRetryTimer, I did not
get the meaning of 'Whatever the setting of this timer, the access node
shall always listen for ANCP session setup.'. I think Access node
triggers the session setup so does it listen for session request as
well.

* In description of ancpAnCurrentSessionTable, its mentioned that:
      A row in this table is created when the corresponding row
      in the ancpAnSessionConfigTable is activated. 

But there is not active field in ancpAnSessionConfigTable which can
activate a row. I think you meant 'created'.

* In description ancpAnCurrentSessionAnName, I think we should reword
the following line: "It should be the same as
ancpAnSessionConfigAnName." In description of ancpAnSessionConfigAnName,
we say that if its value is configured as NULL, we use an appropriate
MAC address.

* I think 'ancpSessionDown' and 'ancpSessionUp' should point to
ancpAnCurrentSessionState and description should say that
'ancpSessionUp' will be sent when the value of object
'ancpAnCurrentSessionState' is set to estab(4) and similarly
'ancpSessionDown' will be sent when the value of object
'ancpAnCurrentSessionState' is moved from estab(4) to any other value.

* As we have made all the four groups in the mandatory-groups, it means
all the devices supporting ANCP to support partitions as well. Do you
really think every device that supports ANCP supports partitions? Can
not we be a little lenient on this and keep this as recommended?

Thanks & Regards,
Bharat

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp

---

From: [email-masked]
Date: Mon, 16 Apr 2007 10:25:01 +0200

Hi Bharat,

Thanks for you comments.  See my answers inline...

> 3. Third table name is not there.

Yes, this would be better.

> implemented by an Access Node?

yes, see compliance statement at the end of the MIB.  As far as I can 
see, none of them can be really made optional altough for some it can be 
considered.

> * I think second paragraph of section 5.3 can be moved to Security

I prefer to keep everything about notifications together.  This is also 
not realy related to security.

> interface of AN [Interface towards the NAS] where ANCP would be

Not sure what you mean here.  Suppose that a DSL line has an ifindex, 
and also the PVCs on the DSL line has ifindexes.  In that case, only the 
ifindex of the DSL line will create a row in the ancpAnInterfaceConfigTable.

> * As per RFC 4181, 'ancpNotifications' should be 'ancpAnNotifications'
yes, and also the 2 notifications need to be adapted.

> from the text. It just says that it will be available.

that's implementation specific.  A get will give an available value but 
it does not matter which one.  Typical implementations will use round robin.

> to each partition. Right?

No, there can be multiple sessions per partition, but a session for the 
moment can only have one partition.  There was some discussion on this 
in the recent past but there was no clear case where it was useful to 
have multiple partitions per sessions.  For the moment the MIB allows 
multiple sessions per partitions, and not multiple partitions per 
session.  Maybe the last part should change even if there is not really 
a good use case for it

> of GSMP in " duration of a GSMP session" -> " duration of a ANCP

ok

> default value 100 i.e. add a value of 100 means 100*100 ms.

This is used quite often and i think it is clear without examples. 
Adding examples would mean doing this for each case where it occurs. 
Look to the UNITS clause, that is there to make it clear.

> triggers the session setup so does it listen for session request as

According to the protocols spec. the AN should set up the session and 
not the NAS.  However, it is somehow strange that when an AN is trying 
to set up a session, that it would forbid setting up a session from the NAS.

> activate a row. I think you meant 'created'.

correct

> we say that if its value is configured as NULL, we use an appropriate

indeed, this sentence is not really clear

> 'ancpAnCurrentSessionState' is moved from estab(4) to any other value.

it is mentioned in the description of the notifications.  I think you 
overlooked this?

> not we be a little lenient on this and keep this as recommended?

The requirement is coming from the framework/req document: "... the 
Access Node MUST support at least 2 partitions...".  Therefore it is 
made mandatory in the MIB as well.

regards,
Stefaan

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 16 Apr 2007 15:36:05 +0530

Hi Stefaan,

    Please see my response in line.

Thanks,
Bharat

> Yes, this would be better.

Ok.

> see, none of them can be really made optional altough for some it can be 

Ok. If they must be implemented than it is fine.

> not realy related to security.

Ok. I just suggested this because I think it makes more sense under
Security Consideration.

> ifindex of the DSL line will create a row in the ancpAnInterfaceConfigTable.

I understand that there can be one or more interface per DSL link. I am
not sure if there are interfaces created for each DSL line separately.
If thats the common practice this should be fine.

In any case, it would be better if you can add this details here.

> yes, and also the 2 notifications need to be adapted.

Ok.

> it does not matter which one.  Typical implementations will use round robin.

Ok.

> session.  Maybe the last part should change even if there is not really 

Ok. I think some more text here will surely help.

> Look to the UNITS clause, that is there to make it clear.

Ok. I thought it might be helpful to be more explicit.

> to set up a session, that it would forbid setting up a session from the NAS.

So its AN which triggers the session than what is it listen for as
mentioned in the above sentence?

> indeed, this sentence is not really clear

Ok. Please make it more readable.

> it is mentioned in the description of the notifications.  I think you 

What I meant is that instead of referencing these notifications to the
object mentioned in the document, they should be referenced to
'ancpAnCurrentSessionState'. Because this object's value decides whether
a Notification should be generated or not.

> made mandatory in the MIB as well.

Ok.

Another thing which I have seen MIB Doctors ask for is that the
REFERENCE clause for Objects. If an object can be referenced to the
protocol/framework document, please add the reference.

---

From: "Moti Morgenstern" <[email-masked]>
Date: Mon, 16 Apr 2007 13:36:00 +0300

Hi,

One comment regarding to the "discussion" on section 5.4: 
There are optionally multiple sub layers over a single DSL line, i.e.,
multiple bearer channels, multiple ATM VPs and VCs, etc.
However, only the bearer channels and the DSL line itself have ifIndex
patterns (each has a different IfType value, which makes it easier to
determine whether or not it requires a row in the
ancpAnInterfaceConfigTable). The ATM entities (VPs and VCs) do not have
ifIndex ! They are all associated with the ifIndex of the ATM interface
(The ATM interface may have a 1:1 relationship with either a bearer
channel or the whole DSL line). 

Regards,
Moti Morgenstern
 
Senior Systems Engineer
ECI Telecom Ltd.
Broadband Access Division
30 Hasivim St.
Petach Tikva, Israel 49517
Tel.:  +972-3-9266258
Fax.: +972-3-9287342 
Cell.: +972-54-5786258
e-mail: [email-masked]

-----Original Message-----
From: Bharat Joshi [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 1:06 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [ANCP] Some comments on ANCP MIB

Hi Stefaan,

Thanks,
Bharat

Ok.

Ok.

Ok.

Ok.

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
solely for the use of the addressee(s). If you are not the intended
recipient, please notify the sender by e-mail and delete the original
message. Further, you are not to copy, disclose, or distribute this
e-mail or its contents to any other person and any such actions are
unlawful. This e-mail may contain viruses. Infosys has taken every
reasonable precaution to minimize this risk, but is not liable for any
damage you may sustain as a result of any virus in this e-mail. You
should carry out your own virus checks before opening the e-mail or
attachment. Infosys reserves the right to monitor and review the content
of all messages sent to or from this e-mail address. Messages sent to or
from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

---

From: [email-masked]
Date: Wed, 18 Apr 2007 10:34:03 +0200

Hi Bharat,

see more inline...

> mentioned in the above sentence?

It is strictly not forbidden for the NAS to set up a session so there is 
no reason why the AN should reject that.  From a protocol point of view 
it would be strange that if a device tries to setup an adjacency that it 
would reject a setup attempt from the other side.  There is no NAS MIB 
but if there would be one, then I guess that in that MIB, there would be 
a similar table as the sessionconfig table in the AN MIB but it would be 
an optional table and not a mandatory table as it is for the AN.  Though 
I do not really have as strong opinion about this, and whatever looks 
fine to me.

> a Notification should be generated or not.

the value of the ancpAnCurrentSessionState is implicit from the 
notification: if case of session up it will always be estab(4) so no 
reason to give this in the notification.  Similar for down: it will not 
be estab(4) anymore.  The list of objects in the notifications is 
already large, so I prefer to reduce as much as possible.

Thanks,
Stefaan