Subject: Re: [ANCP] My review notes for draft-ietf-ancp-framework-12.txt

From: "OOGHE Sven" <[email-masked]>
Date: Sun, 7 Feb 2010 15:40:24 +0100

Hi Hannes and Tina,

Thanks for reviewing, sorry for the delayed response. My proposed
changes are indicated below. I will update the draft accordingly. The
document is now in the RFC-Editor's queue, so I will directly inform the
RFC-Editor Team to make the corresponding changes.

Regards
Sven

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hannes Tschofenig
Sent: zondag 27 december 2009 8:44
To: [email-masked]
Subject: [ANCP] My review notes for draft-ietf-ancp-framework-12.txt

Hi all, 

I just went through
http://www.ietf.org/id/draft-ietf-ancp-framework-12.txt. 

It is a nice and interesting document but I noticed a few minor areas
for improvement. 

0. Terminology

If you cite some ITU-T documents then put the cited text in quotes. If
you modify their definition then say so. 

<Sven> Ok, I will make the changes.

1. Definition of "Multicast flow"

Here is what you have in the draft 

"
   o  Multicast Flow: multicast Any Source Multicast (ASM) group or
      multicast Source Specific Multicast (SSM) (S,G) channel.  An
      application channel (such as a TV channel) is mapped onto a
      Multicast Flow.
"

This does not sound complete nor understandable. 
Looking at RFC 4045 http://tools.ietf.org/html/rfc4045 I can find the
following definition:

"
   Multicast flow

      Designates datagrams sent to a group from a set of sources for
      which multicast reception is desired.
"

Maybe this is more appropriate? 

<Sven> Agreed, I will update the second definition but adding a few
words on ASM (*,G) and SSM (S,G) multicast.

3. "General Architecture Aspects" Section 

The "Access Node Control Mechanism" term is described as 
"	  
   o  Access Node Control Mechanism: a method for multiple network
      scenarios with an extensible communication scheme that conveys
      status and control information between one or more ANs and one or
      more NASs without using intermediate element managers.
"

There are two concepts that readers are typically familiar with, namely
a protocol and an architecture. 
The main product of the working group is the protocol. The architecture
already exists elsewhere, namely largely in the Broadband Forum (former
DSL Forum) and there is potential (maybe) applicability elsewhere (e.g.,
IEEE 802.16). 

Now, Section 2.1 describes something that others would typically call
"architecture". Section 2.2 is a mixture of a) description of Figure 1,
and 
b) the text provides an instantiation of the architectural figure shown
in Section 2.1. 

Section 2.3. has the fancy title of "Access Node Control Mechanism
Transport Methods". What this section only does is to discuss how QoS
treatment of control traffic can be accomplished when used over Ethernet
and ATM networks. I don't think that this is crucial for the description
of the architecture but your view might be different. Maybe there is a
chance to provide a better introduction to this section and a different
title for the section. Something like "Preferential Treatment for
Signaling Traffic" or "Separating Signaling and Control Traffic".

Section 2.4 is also not very fortunate with regard to the section
heading. "Operations and Management" is a rather broad term and you
address only a very specific aspect in this section, namely the
challenge of having more than one management entities and the potential
conflicts that may arise. 

Overall, I believe that there is something wrong with the structure of
Section 2. The introduction of Section 2 talks about two aspects that
are described but then there are 5 sub-sections, with an unclear
relationship among either other. Some "glue" is missing here. 

<Sven>
I will update the beginning of section 2:
"This section introduces the basic concept of the Access Node Control
Mechanism and describes the reference architecture where it is being
applied. Based on the reference architecture, the section then describes
how Access Node Control messages are to be prioritized over other data
traffic, and the interaction between ANCP and the network management
system. Finally, the addressing schemes are described that allow
identifying an Access Port in Access Node Control messages."

. I will update the title of section 2.3 to " Prioritizing Access Node
Control traffic" and add following description:
"When sending Access Node Control messages across the aggregation
network, care is needed that messages won&apos;t get lost. The
connectivity between the Access Node and the NAS may differ depending on
the actual layer 2 technology used (ATM or Ethernet). This section
briefly outlines how network connectivity can be established."

. I will update the title of section 2.4 to "Interaction with management
systems"

4. Figures have a title.  

Figure 1 is missing a title. 

<Sven> I will add the title.

5. Abbreviations

When you introduce abbreviations please expand them (otherwise you will
be asked again by the RFC Editor later). 

<Sven> I will cross-check and update.

6. "Access Node" and other terms. 

Section 1.2 defines the term "Access Node" and Section 2.2.3 defines it
again. 
The same is true for "Network Access Server" defined in Section 1.2 and
again defined in Section 2.2.6.  

<Sven> I will remove the definitions in section 2.2.3 and 2.2.6. 

7. Justify your statements

When you talk about other mechanisms being error prone and complex then
you need to provide a discussion why they are error prone or more
complex than the mechanism being proposed here to gain credibility. 

Example:

"
   OSS systems are rarely able to enforce in a reliable and scalable
   manner the consistency of such data, notably across organizational
   boundaries. 
   The Access Topology Discovery function allows the NAS to
   perform these advanced functions without having to depend on an
   error-prone & possibly complex integration with an OSS system.
"

<Sven> I will reword as follows:
"OSS systems are typically not designed to enforce the consistency of
such data in a reliable and scalable manner across organizational
boundaries. The Access Topology Discovery function is indended to allow
the NAS to perform these functions without having to rely on an
integration with an OSS system."

8. Section 3.2 - OPEX

I have a question regarding the OPEX statement in the following
paragraph:

"
   Access Loop rates are typically configured in a static way.  When a
   Subscriber wants to change its Access Loop rate, the network operator
   needs to reconfigure the Access Port configuration, possibly implying
   a business-to-business transaction between an Internet Service
   Provider (ISP) and an Access Provider.  From an Operating
   Expenditures (OPEX) perspective this is a costly operation.

   Using the Access Node Control Mechanism to change the Access Loop
   rate from the NAS avoids those cross-organization business-to-
   business interactions and allows to centralize Subscriber-related
   service data in e.g. a Policy Server.
"  

I guess I understand that there are still two organizations involved but
you essentially claim that by using some protocol mechanisms the OPEX
cost would be reduced compared to a potential human interaction as it is
done today. 
Is my understanding correct? 

<Sven> Yes, that's correct.

9. Section 5 "Policy Server Interaction" is useless. Maybe better to
delete this section?

<Sven> Given that it is already captured elsewhere in the document, I
see no need to keep section 5. If no-one objects I will remove it.
  
10. Editorial issues 

Let some native English speaker read through the text to make sure that
the language, punctuation, etc. problems get fixed. 

<Sven> During Last Call the draft was reviewed by several native English
speakers - if there are other edits to be done please let me know.

Thanks
Sven

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