Subject: [ANCP] Some questions and suggestion on draft-wadhwa-gsmp-l2control-configuration-02.txt

From: "bharat_joshi" <[email-masked]>
Date: Fri, 24 Nov 2006 20:21:56 +0530

Hi,

    I have couple of questions and suggestion on the document describing gsmp-l2control-configuration.

* There are some issues in the format of this draft. Page numbers in 'Table of contents' does not seems to be properly formatted.

* "Conventions used in this document" contains the same text as in "Specification Requirements". I think this text are genrally added under "Terminology" section.

* If you are not using xml2rfc, I would suggest you to use it.

*  This draft uses lots of short-forms so it would be a good idea to add a Terminology section which describe all these terms.

* Typo in Introduction. "In the scope of these specification" -> "The scope of these specification"

* I think it can be mentioned somewhere that if there are GSMPv3 enabled switches in Network, they would discard these extended messages based on the version.

* In section 3.1, towards the end of the 4th paragraph, there is something missing in the following sentence:

" relieving a potential requirement for them to build infrastructure to attach more directly to the various Access Networks."

* In section 3.1, 7th paragraph, I feel following statement need to be rephrased:

"In order to allow IP QoS support over an existing non-IP-aware layer 2 access network without using multiple layer 2 QoS classes, a mechanism based on hierarchical scheduling is used."

Something like:

A mechanism based on hierarchical scheduling can be used in BRAS to allow IP QoS support over an existing non-IP-aware layer 2 access network which does not use multiple layer 2 QoS classes.

* In section 3.2, We have seen some of the networks using [1:1] PVC-VLAN as one of the other ways to create virtual circuit. In this case, one PVC in AN is statically attached to one VLAN. I am not sure if you want to add this to the text.

* In section 4.1, I think 'protocol' can be added in 'control plane' in the following statement:

"There is a requirement for a control plane between service-oriented"

* In section 4.1, statement "optimized multicast replication to enable video services over DSL," is not entirely True. Please correct me if I am wrong, ANCP is used to configure AN with only those Multicast addresses for which a user is authorized. Actually speaking, the same thing could have been achieved using IGMP snooping but in that case, we can not authorize because User's profile is with BRAS. So what I meant is that ANCP actually helps in restricting access of Multicast traffic to those who are authorize to receive it. Optimization of Multicast replication could have been achieved using IGMP snooping.

* In section 4.2.1, please rephrase the first statement in the 2nd paragraph. It could look as follows:

Across organizational boundaries, OSS systems are rarely able to enforce consistency of such data in a reliable and scalable manner.

* In section 4.2.2, its mentioned that BRAS needs to learn the initial attributes of DSL line before the subscriber logs in and access the provisioned service. How is this achieved?

* In figure 2, Does 'DSL signal' means that DSL port is UP? or is it that DSL line has seen signal and gets into training mode?

* In section 4.3.1, last line on 4th paragraph:
"conveyed by the BRAS in ANCP." -> "conveyed by the BRAS via ANCP."

* In section 4.4, protocol support for ANCP transactional Multicast will be provided in future. If required, We can help in creating a document with the use-cases.

* In Port-management messages, what is the identifier of the port?

* Title for section 4 and 5 is same. You may want to change one of them.

* Why do we need to use TCP as the transport here? It could have been on top of IP like other protocols. We also have a keep-alive to keep the adjacency between NAS and AN.

* Its not clear whether the keep-alive messages contains Capability TLVs as well. Also there are couple of fields in the messages which are not described like partition-id.

* In section 5.3, its mentioned that capability data field can be empty if its a boolean capability. Does this mean that if a capability is not included, its not enabled?

* I think new capability types MUST be allocated by IANA.

* In section 5.4.1.1, first statement in the description of 'Extension Value' is not clear. Can you please rephrase this?

* While explaining that what field in a message is being set to what value, I think it would be good if its done in point wise. For example: in section 5.4.2. I think its more readable if we write that in following way:

   o The GSMP Event message with PORT UP message type (80) is used for
     conveying DSL line attributes to the BRAS.

   o The version field should be set to 3, and the sub field should be
     set to 1.

   o The I and subMessage fields SHOULD be set to 1 to signify no
     fragmentation.

   o The Port and Label fields should be set to 0.

   o The “Port Session Number” should be set to 0, and the “Event
     Sequence Number” should be 0.

   o The Tech Type field is extended with new type "DSL". The value for
     this field is 0x05.

   o The message SHOULD be generated when a line first comes UP, or any
     of the attributes of the line change e.g. the line re-trains to a
     different rate or one or more of the configured line attributes
     are administratively modified.

* Though fields in these messages is defined in GSMP RFC but I feel that we should at least mention the use of each field in this draft as well.

* What are Encaps PPPoA NULL, IPoA NULL?

* In section 5.4.4, Out of the three TLVs to identify circuit-id, I think it should say that atleast one MUST be available.

* How is the last 2 bytes of Type(OAM-Loopback-Test-Parameter) need to be populated by BRAS or processed by AN?

* If the timeout is zero, does AN need to generate a reply of the test? if yes, if AN used an in-house timer but could not complete the test, what should it do?

* How do AN identified whether it needs to generate F4 OAM cell or F5 OAM cell?

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