Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-ancp-framework-10

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Aug 2009 15:19:07 -0500

Sorry for the late reply--this one got buried in a deluge of pre-IETF  
meeting mail. Comments inline.

On Jul 14, 2009, at 3:45 PM, OOGHE Sven wrote:

> Ben,
>
> Thanks for commenting on the draft. See my feedback inline.
>
>
> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: maandag 29 juni 2009 23:55
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; OOGHE Sven; [email-masked]
> Cc: Jari Arkko; [email-masked]
> Subject: Gen-ART LC review of draft-ietf-ancp-framework-10
>
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-ancp-framework-10
> Reviewer: Ben Campbell	
> Review Date: 2009-06-29
> IETF LC End Date: 2009-06-29
> IESG Telechat date: (if known)
>
> Summary:
>
> This draft is on the right track, but has issues that need work prior
> to publication.
>
> Major issues:
>
> -- Section 4.1, first bullet:
>
> I am concerned that a catchall "address all the use cases" requirement
> is too vague. For the most part, the use cases are not in
> "requirements language". It's going to be hard to gauge compliance
> without analyzing the use cases to extract concrete requirements,
> either now or in the future. (I note that you have requirements
> breaking down some of the use cases, but not all.)
>
> <Sven> The purpose of the framework is to describe use cases that will
> then be addressed by the ANCP protocol in protocol-specific documents.
> In that respect, the first part of the requirement is fairly vague. I
> suggest to reword the requirement so that it reads the following:
>
> "The ANCP MUST be easily extensible through the definition of new
> message types or TLVs to support use cases beyond those currently
> addressed in this document (this includes the use of Access Nodes
> different from a DSLAM, e.g. a PON Access Node)."
>

Okay, I think that helps.

> -- 4.7.8:
>
> The draft should describe (or reference a description of) the
> wholesale model, how it differs from other models, and what the
> relationship between wholesalers and retailers. This sounds like a
> business model, but what does it mean technically?
>
>
> <Sven> I will add a reference to Broadband Forum TR-058, TR-059 and
> TR-101, which describe a DSL broadband access architecture and how it
> enables wholesaling.

This helps--but I am skeptical that the average reader will follow up  
on those references. I think a short (i.e. few paragraphs) high-level  
description of the technical aspects of the wholesale model would be  
useful in this draft.

>
> -- 7 (security requirements)
>
> This draft depends almost entirely on draft-ietf-ancp-security-threats
> for its security requirements. The security requirements in that draft
> are substantial. However, this draft only mentions that document in
> passing, as an informational reference. I think that needs to be a
> normative reference, with explicit language in this draft stating that
> those requirements are incorporated. (I understand this draft is
> informational track, but it's stating requirements on protocol  
> design.)
>
> <Sven> I will move the reference to the normative references section,
> and add a statement to section 7 that "The ANCP MUST comply to the
> security requirements spelled out in draft-ietf-ancp-security- 
> threats."

Okay, that helps.

>
> Minor issues:
>
> -- Section 2.4: The document seems to assume RADIUS is the only AAA  
> protocol. Is RADIUS the only such protocol in scope? That is, no
> DIAMETER or other potential AAA protocols?
>
> <Sven> I suggest to reword to "Policy or AAA Server" and not mention
> what particular protocol will be used to communicate to the AAA  
> Server.

Okay.

>
> -- Section 3.4.1, paragraph 6:
>
> I sounds like anything not on the white or grey list is effectively on
> the black list, right? Then why have an explicit black list at all?
>
> <Sven> Anything dat doesn't match the white or grey list, will  
> indeed be
> dropped by default. An explicit black list however is still useful,  
> e.g.
> in the following config:
>
> . White List entry <S=*,G=*>
> . Black List entry <S=*,G=g.h.i.l>
>
> In this case, the default behavior is to accept the flow (matching the
> catch-all entry in the white list). However, when joining group IP
> address g.h.i.l, the most specific match would apply and the request
> would be rejected.
>

Ah, good point--I was not thinking about wildcard entries. I withdraw  
the comment.

> -- section 4,1, second bullet:
>
> This is vague--can you enumerate or reference the "various
> technologies"? Even if they are mentioned elsewhere in the doc, it
> would be good to reference them.
>
> <Sven> I will edit to clarify that it refers to ATM and Ethernet.
>

Okay.

> -- 5th bullet:
>
> "fast-paced" is vague--can you state something more concrete?
>
> <Sven> I will solicit the ANCP WG for feedback.
>

Okay.

> -- 6th bullet: 
>
> Why 5000? What is the motivation behind that particular number?
>
> <Sven> That value was concluded after discussing with operators on a
> typical network deployment.

Okay.

>
> -- 4.3, first bullet:
>
> Can you characterize how "limited"?
>
> <Sven> Basically, the protocol must be designed to only require a
> software upgrade, not a hardware upgrade. Perhaps the requirement  
> should
> be reworded to the following:
> "The ANCP MUST be simple and lightweight enough to allow an
> implementation on Access Nodes that does not specifically require
> additional control plane resources (e.g. additional CPU and memory
> requirements). "

This still seems vague to me without some characterization of a  
typical access node platform. I would be surprised if there are not a  
broad range of device "size" for this sort of thing. I'm not looking  
for precise hardware specs, but it would help to have some idea of the  
typical range of CPU and memory resources you are thinking about.

>
> -- 5th bullet: (use case negotiation)
>
> Is this limited to the use cases in this draft, or is this intended as
> an extensibility mechanism?
>
> <Sven> It is intended to refer to present and future use cases. I will
> reword.

Okay.

>
> -- 4.6.2, 1st bullet:
>
> SHOULD use, or SHOULD be able to use? If the former, why? What harm is
> done by using separate facilities?
>
> <Sven> The purpose of this requirement is to state that there is no  
> need
> to have dedicated links between the AN and the NAS just for the sake  
> of
> running the ANCP protocol. This is not really a protocol design
> requirement, but rather a deployment guideline. I will change "SHOULD"
> to "should".

The previous paragraph talks about some deployment considerations--I  
took this paragraph as suggesting that implementors allow certain  
configurations, rather than that deployments should use certain  
configurations. Am I misunderstanding the intent?

>
> -- 4.6.3:
>
> Is this reasonably in scope? This sounds more like a product
> requirement than a protocol requirements. (This comment replies to
> several other requirements concerning interactions with network
> management.)
>
> <Sven> It indeed is a nodal requirement. As it is intended as a
> guideline, the nodal requirements always use uncapitalized "must" /
> "should".

Okay. (Remember that the comment applied to other statements about  
network management as well.)

>
> -- 4.6.7, 2nd bullet (also 4.7.7, 2nd bullet)
>
> Can you elaborate on the requirements to "dampen notifications"?
>
> <Sven> Proposed rewording "The Access Node should be able to avoid
> sending bursts of ANCP messages related to notification of line
> attributes or line state by spreading message transmission over time."

Okay.

>
> Nits/editorial comments:
>
> --Section 1, paragraph 1: Please expand ONU on first use.
>
> <Sven> ONU = Optical Network Unit

Okay

>
> -- Section 3.1, second bullet: first sentence is a fragment.
>
> <Sven> "Allow for a better utilization of network resources"
>

Okay

> -- Section 3.4.1, White, Black, and Grey list entry descriptions:
>
> Is this notation (e.g. <<G=g.h.i.l> ) well known? Is there a
> description that can be referenced?
>
> <Sven> The notation is inspired on (S,G) and (*,G) notation for
> multicast. No reference exists to my knowledge...
>

Okay

> -- section 3.4.2, paragraph 3: "...AN and NAS MUST ensure admission  
> control..."
>
> Does it make sense to use normative language in a use case  
> description?
>
> <Sven> No, normative language is not appropriate here. I will change  
> to
> "must"
>

Okay

> -- section 4 and subsections, general:
>
> There are enough bulleted requirements in section 4 that it would be
> really helpful to have them numbered. Otherwise, you're going to have
> to talk about "The nth bullet in section X.Y.X" when you discuss
> specific requirements.
>
> <Sven> I will number the requirements.
>

Okay

> -- last bullet on page 30: "This MUST allow to retrieve... " 
>
> <Sven> I will reword the second sentence to "This MUST allow a
> management station to retrieve statistics and alarms (e.g. via SNMP)
> related to the operation of the ANCP, as well as to allow it to  
> initiate
> OAM operations and retrieve corresponding results."
>

Okay

> Missing word(s)?
>
> -- 4,3, 2nd bullet: "... allowing to inform ..." --  missing word(s)?
>
> <Sven> Should be edited to "...allowing the protocol to inform..."
>

Okay.

Thanks!

Ben.

---

From: "OOGHE Sven" <[email-masked]>
Date: Wed, 12 Aug 2009 16:56:40 +0200

Ben,

Thanks for reviewing. Below my feedback on the "open" items.

<Sven> Fair point, I will write a paragraph and add it to an updated
draft.

<Sven> I'm not sure we should start writing about hardware components /
memory sizes / CPU types in the draft. How about I write the following:

"The ANCP MUST be simple and lightweight enough to allow an
implementation on Access Nodes to run without specifically requiring a
hardware upgrade"

<Sven> The first bullet is a deployment consideration but has no impact
on the protocol design. I will add a note to the requirement to make
this clear.

<Sven> I cross-checked the latest version - all nodal requirements
related to network management use uncapitalized "must" / "should". So
this is covered.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 12 Aug 2009 10:35:14 -0500

Hi,

I think we are in agreement on all except the following:

> implementation on Access Nodes to run without specifically requiring a

How would you test compliance with a requirement like that?

Is there a way you can recast it to describe certain aspects of the  
protocol itself? For example statefulness, encoding types, etc?

Another approach might be to make it even more general, and say the  
protocol specification should discuss imbedded system implementation  
considerations--which I suspect is close to the intent of the original  
language.

Thanks!

Ben.