Subject: [ANCP] Some questions and suggestion on Framework document..

From: "bharat_joshi" <[email-masked]>
Date: Mon, 20 Nov 2006 09:34:56 +0530

Hi,

    I have couple of questions and suggestion on the ANCP framework
document
[http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-00.txt]:

* In Introduction, statement 'In the scope of these specifications' is
not very clear. I think it may be changed to "The scope of these
specifications'

* In Introduction, second paragraph, statement 'departments operating
the IP network interworking at the management plane is not always
possible' is not clear. I think either a comma [,] between 'network' and
'networking' will make it clear or change the statement as follows:

'Interworking at the management plane is not always possible because of
the organizational boundaries between departments operating the local
loop, departments operating the ATM network and departments operating
the IP network'

* When these 'Information Reports' are generated? Figure 1 shows that
these reports are generated by AN. Are these reports periodically
generated? What kind of information is passed through these reports? I
did not find any reference to this in the document.

* In section 2.4.1, through we talk about port-addressing schemes but we
are not actually referring to ports here. There are configurations where
we can have multiple user sessions and 'Circuit-Id' would be different
for each one of them. So what I want to say is that we are identifying
the circuit instead of ports. So you may want to change the section
title to something which reflects the same.

* I am trying to understand the need of communicating DSL line data rate
to NAS for each user. Does it anyway help in over-subscription on NAS? I
can understand that NAS can modify its scheduling parameters for a given
user based on the line data rate provided by AN but what is the
advantage?

* In Access loop configuration, Its mentioned that Access loop
configuration is available with the Access provided which controls the
DSL line profile in Access Node. Now subscriber wants some changes in
it, its mentioned that ANCP can propagate this change without an
operator intervention using policy server. My question is if ANCP is
down and during this time, a change happens, how would the system react?
This change may have happened in the Access Node but NAS may not be
aware of this change. Is this correct?

* Does ANCP require a configuration of 'upstream router port' [interface
to reach NAS] in ANs? or does it run a protocols to figure out the
interface on which it can reach to the upstream router [NAS]
dynamically?

* In section 4.1, Point #4. Last line could be modified to use the word
"atomic".

* In section 4.2, point #4. As ANCP is mapped on top of IP, there is not
inherent support of reliability, so how do we take care of the
reliability here? Do we send the ANCP message multiple times?

* Section 4.2 does not mention any requirements for authentication
before ANCP sessions are created? How do we handle authentication here?

* In section 4.4.1, how does a logical port treated here? Can a logical
port built on top of a physical port be attached to a different
partition?

* In section 4.4.2, statement "If an Access Node in street cabinet
installation is connected to a NAS all user and Access Node Control data
use the same physical link" is not clear. I think we need a comma [,]
between 'NAS' and 'all user' and also change 'all user' to 'all users'
as follows:

"If an Access Node in street cabinet installation is connected to a NAS,
all users and Access Node Control data use the same physical link.

* In section 4.4.2, statement, "If ATM interfaces are used VPI as well
as VCI value MUST be configurable in the full range." is not clear. I
think a comma [,] needs to be added between 'used' and 'VPI'. It may be
corrected as follows:

"If ATM interfaces are used, VPI as well as VCI value MUST be
configurable in the full range."

* In section 4.4.6, can we combine multiple ANCP messages in single
message? This may help in saving some CPU cycles in AN and NAS.

* In section 4.4.7, I think providing configuration for each parameter
which can be modified using ANCP, would be a little too much. Though
this depends upon the parameters available for configuration but I think
it would be good if it is done for a group of parameters. Something like
'Multicast-group', which if enabled can result in modifying certain
parameters related to multicast.

* I think if possible, we should add the security consideration in both
Access Node requirements as well as NAS requirements.

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: Thu, 23 Nov 2006 12:26:20 +0100

Hi Bharat,

Please find our answers inline.

> not very clear. I think it may be changed to "The scope of these

<Sven>
Ok
</Sven>

> loop, departments operating the ATM network and departments operating

<Sven>
We'll use your suggested text.
</Sven>

> did not find any reference to this in the document.

<Sven>
The Information Reports in Figure 1 indicate messages that are sent by 
the Access Node towards the NAS. The intent was to show the conceptual 
message flow in figure 1. The actual use of these flows depends on the 
use case. For instance, in case of "Dynamic Access Loop Attributes" 
these messages are sent when the DSL Network Termination (DSL modem) is 
turned on, or when the DSL net data rate changes overtime.
</Sven>

> title to something which reflects the same.

<Sven>
The intent is indeed to address the logical ports, which could be an ATM 
PVC or an Ethernet VLAN on top of a physical DSL port. If we chage the 
text to reflect "Locial port addressing", would that be ok?
</Sven>

> user based on the line data rate provided by AN but what is the

<Sven>
Have a look at section 2.9, item (3) in TR-101:
http://www.dslforum.org/techwork/tr/TR-101.pdf
It describes the rationale for knowing the actual DSL net data rate at 
the level of the NAS. More info can also be found in TR-059.
</Sven>

> aware of this change. Is this correct?

<Sven>
The assumption we take is that when the use case "Access loop 
configuration" is used, the profile to be used on the access loop will 
be stored in a central policy system. If the ANCP session is down, no 
changes should happen to the access loop configuration.
If for some reason a change happens, we assume that this translates in a 
certain (new) DSL net data rate when the line is operational again. At 
that point, the Access Node will send this information to the NAS, which 
can take a corrective action if needed (e.g. change to another profile 
on the Access Node).
</Sven>

> interface on which it can reach to the upstream router [NAS]

<Sven>
This aspect is not touched upon in the framework description. The 
assumption we take is that the interface is configured.
</Sven>

> * In section 4.1, Point #4. Last line could be modified to use the word

<Sven>
Ok
</Sven>

> reliability here? Do we send the ANCP message multiple times?

<Sven>
In case ANCP is mapped on top of IP, then the logical consequence is 
that reliability - when needed - must be built into the protocol. How 
that is done will not be described in the framework but is part of the 
protocol specification work.
Note: we expect these requirements will be significantly reworked in an 
update. It would be good to give it a re-read once we've updated the 
framework.
</Sven>

> before ANCP sessions are created? How do we handle authentication here?

<Sven>
Good point. Security and authentication are not yet touched upon. Our 
idea at present is to refer to a separate document that would define 
those. draft-moustafa-ancp-security-threats-00.txt provides input on his.
</Sven>

> port built on top of a physical port be attached to a different

<Sven>
Our assumption at this point is that all logical ports on top of the 
same physical port will be associated with the same partition. In other 
words, partitioning is performed at the level of the physical port only.
</Sven>

> all users and Access Node Control data use the same physical link.

<Sven>
Ok
</Sven>

> configurable in the full range."

<Sven>
Ok
</Sven>

> message? This may help in saving some CPU cycles in AN and NAS.

<Sven>
Section 4.4.6 sets the high level requirement for this, but does not go 
into the details of how this can be achieved. Combining multiple 
messages into a single message is one way, which is also how it is 
proposed in draft-wadhwa-gsmp-l2control-configuration-02.txt
</Sven>

> parameters related to multicast.

<Sven>
This section needs some reworking/clarification. Having parameter 
control at the granularity of individual parameters may be a bit too 
much. We'll rework the section.
</Sven>

> Access Node requirements as well as NAS requirements.

<Sven>
How about referring to a separate security document 
(draft-moustafa-ancp-security-threats-00.txt)? Would that make sense?
</Sven>

Regards,
Sven

---

From: "bharat_joshi" <[email-masked]>
Date: Thu, 23 Nov 2006 21:58:31 +0530

Hi Sven,

   Thanks for your reply. Please see my response in line. I have removed those questions/suggestions where we both are in sync.

Thanks & Regards,
Bharat

> We'll use your suggested text.
Ok.

> turned on, or when the DSL net data rate changes overtime.
Actually it would be good if you can add two lines to text explaining about the Information Reports.

> text to reflect "Locial port addressing", would that be ok?
I am not sure if we can call them a Logical port. Generally, there are different VCs which have different User sessions so it could be called circuit-addressing scheme or something in similar lines.

> the level of the NAS. More info can also be found in TR-059.
Though this draft refer to TR-101 but as ANCP can be used in not only for DSL environment I would suggest to add some of these details here. This will make sure that people from other type of Access Networks need not go back to TR-101 to understand the need of it.

> can take a corrective action if needed (e.g. change to another profile
Please correct me if I am wrong here. I assume that when some particular configuration for a user needs to be changes, it is done in the policy server. NAS picks it up from the policy server and pass it on the Access Node using ANCP. Now when ANCP is down, this is not possible. What I understand from this is if any such configurations that NAS passes to AN using ANCP, will not take any affect until ANCP is down.

So what I meant is that if a user configuration changes when ANCP is down though user would expect the changes to take place immediately, it may not happen.

Please let me know if I am missing something here.

> assumption we take is that the interface is configured.
I think it would be good if we can create a section for Assumptions in the document and add such details there.

> update. It would be good to give it a re-read once we've updated the
Ok. I shall check this in the next revision of the draft.

> those. draft-moustafa-ancp-security-threats-00.txt provides input on his.
I have not read though that document yet. I think you would be adding the reference only when this draft becomes a Working Group Item.

> words, partitioning is performed at the level of the physical port only.
Ok. I think it would be a good idea to add this to the new section Assumptions.

> proposed in draft-wadhwa-gsmp-l2control-configuration-02.txt
Ok. I am going through this document but still to complete my review. Let me check if this has been addressed here.

> much. We'll rework the section.
Ok. I shall check the same in the next revision of the draft.

> (draft-moustafa-ancp-security-threats-00.txt)? Would that make sense?

I am sure that there are lot of things to consider in the security consideration and a separate document does make sense.

---

From: [email-masked]
Date: Fri, 24 Nov 2006 09:31:48 +0100

Hi Bharat,

See inline.

> Actually it would be good if you can add two lines to text explaining about the Information Reports.

<Sven>
Ok, we'll add a few sentences to explain its purpose.
</Sven>

> I am not sure if we can call them a Logical port. Generally, there are different VCs which have different User sessions so it could be called circuit-addressing scheme or something in similar lines.

<Sven>
I kind of preferred "logical port" since circuit matches the ATM VC, but 
is less appropriate for Ethernet VLAN IDs...

Let me suggest the following: we will change the title to "Circuit 
addressing scheme" and be explicit on what it means in the paragraph 
below, unless someone else on this list argues why not to use this name.
</Sven>

> Though this draft refer to TR-101 but as ANCP can be used in not only for DSL environment I would suggest to add some of these details here. This will make sure that people from other type of Acces…

<Sven>
That's fine.
</Sven>

> Please let me know if I am missing something here.

<Sven>
You're correct. If the ANCP session is down, it cannot be used to change 
some of the Access Node parameters. In this case, the NAS could for 
instance report this to the policy management system which triggered the 
configuration action. The latter could then use application specific 
signaling towards the customer to notify him about the fact that the 
change could not be performed at that time.
</Sven>

> I think it would be good if we can create a section for Assumptions in the document and add such details there.

<Sven>
I agree that this needs to be added to the document somewhere, either in 
a separate "Assumptions" section, or in one of the existing sections. 
We'll look into this.</Sven>

> I have not read though that document yet. I think you would be adding the reference only when this draft becomes a Working Group Item.

<Sven>
This is the assumption, yes.
</Sven>

> Ok. I think it would be a good idea to add this to the new section Assumptions.

<Sven>
We'll for sure add this to the document. I'm not yet convinced of the 
need for a dedicated "Assumptions" section for this. Are you ok if we 
decide this during updating?
</Sven>

> I am sure that there are lot of things to consider in the security consideration and a separate document does make sense.

<Sven>
Ok, great. BTW some weeks ago, the chairs issued a call for review of 
draft-moustafa-ancp-security-threats-00.txt and whether or not people 
support this draft becoming a working group ID.
</Sven>

Regards,
Sven

---

From: Bharat Joshi <[email-masked]>
Date: Fri, 24 Nov 2006 14:25:51 +0530

Hi Sven,

   Thanks for your reply. Please see my response in line. I have removed
those questions/suggestion where we both are in sync.

Thanks,
Bharat

> below, unless someone else on this list argues why not to use this name.

Sounds good to me.

Ok.

> Please correct me if I am wrong here. I assume that when some
> particular configuration for a user needs to be changes, it is done in
> >the policy server. NAS picks it up from the policy server and pass it
> >on the Access Node using ANCP. Now when ANCP is down, this is not
> >possible. What I understand from this is if any such configurations
> >that NAS passes to AN using ANCP, will not take any affect until ANCP
> >is down.
> > So what I meant is that if a user configuration changes when ANCP is
> down though user would expect the changes to take place immediately,
> it may not happen.
> > 

If a user wants his bandwidth to be increased and ANCP is down, this may
take some time to happen. So I feel it need to be mentioned here.

Ok.

> decide this during updating?

Yes. That should be fine.

> support this draft becoming a working group ID.

Ok. I shall take a look at this document and pass on my comments to
author if I have any.

---

From: [email-masked]
Date: Fri, 24 Nov 2006 15:52:08 +0100

Hi Bharat,

We'll put in a few words on the scenario when a user wants his bandwidth 
to be increased but the ANCP session is down.

Thanks again for the in-depth review.

Regards,
Sven