Subject: [ANCP] IETF 69 ANCP meeting minutes

From: "Wojciech Dec \(wdec\)" <[email-masked]>
Date: Tue, 31 Jul 2007 12:42:53 +0200

Hi All,

Here are the IETF 69 ANCP WG's meeting minutes, and actions items.
Thanks to all, and in particular to our scribe Jeremy.

* ACTION Item Summary

ACTION #1  Chairs: Update milestones
ACTION #2 ANCP working group: Review WT-147 and determine deltas (if
any).
ACTION #3 Chairs; draft a liaison to DSLF.
ACTION #4: Chairs to issue last call for security draft.
ACTION #5 Sanjay: Initiate WG mailer discussion on graceful restart and
line bonding.
ACTION #6: Matthew - to send out mail to WG with observations about
protocol draft's use for other technologies.
ACTION #7: Chairs - confirm multicast direction on list.

Regards,
Woj & Matthew

ANCP WG IETF 69meeting minutes
TUESDAY, July 24th, 2007: 15:20 - 17:20
-------------------------------------------
CHAIRS: Wojciech Dec & Matthew Bocci

***
5 mins - Administrivia : Chairs

We're clearly past the shown milestones.

Agreed for pushing milestones out by about 6 months for all outstanding
items.  Mar 2007 becomes Oct 2007.
Security requirements doc ready for last call.

Sanjay Wadhwa - Still discussion on multicast use case.  Protocol
depends on Framework and Requirements.

ACTION #1  Chairs: Update milestones

***
5 mins - Liaisons : Chairs

Received a liaison from DSLF inviting us to refer to WT-147.  Includes
an invitation to DSLF in Nashville.

Wojciech Dec : How many people have read the WT-147 liaison. None.

Hassnaa Moustafa : Don't see the coherency between the WT-147 use cases
and the wg defined use cases. Is the ANCP protocol suitable for the
use-cases identified in WT-147. Decision should be made by ANCP WG.

Wojciech Dec : Multicast discussions have been going on for some time in
DSL Forum and are still ongoing. WT147 however contains more multicast
use-case content than the WG's ANCP Framework doc.
The ANCP framework doc derives from the WT-147 framework, so all uses
would appear to be covered. Feedback on this from additional WT-147
reviewers would be welcome.

ACTION #2 ANCP working group: Review WT-147 and determine deltas (if
any).

Mark Townsley - Since this is a reply from an earlier WG liaison, we
might just send a courtesy reply. 
Wojciech - It does seem like the DSL Forum?s reply was a response to our
previous liaison. 
Mark Townsley - Ping-pong courtesy replies perhaps not needed then, but
we could reply saying "Thank you for the liaison. We've asked the WG to
review the doc, etc".

ACTION #3 Chairs; draft a liaison to DSLF.

***
15 mins - ANCP Framework / Requirements - Dong Sun
([email-masked])
http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-
02.txt

Presented on behalf of Sven.
Main updates:
Multicast section as per consensus from last meeting.
Made network element requirement informative
Other edits as per comments.

Multicast - Resource efficient multicast increasing in importance.
Requires local replication in access node.
In order to maintain backward compatibility, AN and NAS to behave like
black box.
Implementation of multicast behavior between AN and NAS will not be
specified.
How to proceed? Can we consider draft complete? 
Framework is not considered complete (from audience).

Wojciech Dec : How many people have read the latest doc? Approx 5 people
raise hands.

Dong asks for comments about doc.

Francois Le Faucheur : Multicast section requirements are woefully
incomplete.  Can't write a protocol from this level of detail.  Either
we add more detailed multicast requirements or we define multicast out
of the scope of present Framework document. Believe that we need to add
same level of detail as for other use-cases. 

Dong : Wasn't there consensus at the last meeting to keep protocol
details out of the framework?

Wojciech Dec: Last meeting had consensus on the scope, detailed protocol
work is for the protocol spec.

Mark : Framework doc is a tool to let the WG come to consensus. If it's
a tough issue, maybe it needs even more details than non contentious
items. Ultimate output of IETF is a protocol not a framework. Fact that
there is a lot of discussion on multicast indicates that more detail
needs to be spelled out. 

Matthew Bocci: There must be at least an equivalent level of detail in
the multicast requirements as for other use cases.

Sanjay Wadhwa: Doesn't see the detailed message flows in the framework
doc.

Mark: didn't hear that suggested
Woj (expressing opinion): Detailed flows not in framework, but message
primitives yes.

Francois: Other use-cases have 2-3 main things in framework. 1.
Description of use-case 2. description of message exchange. 3
Requirements for protocol. Those three also needs to be in framework
document for multicast. The exact message flow should not go into
framework but instead in protocol draft.

Woj: Seems like we have consensus. Any comments?

Jeremy Brayley : Depends how much the primitives define the protocol. Eg
one might solve things differently than by having message from
Access-Node to NAS. Way use-cases written so far is it describes why a
message is to be sent.
Woj: Does the framework and requirements doc need to contain enough
detail to write the protocol for the multicast use-case.

Jeremy : Yes. Separate protocol document describes the flows. Maybe even
the primitives.

Woj: Key point is the primitives. From what we've heard so far,
primitives are to be in the framework doc.

Mark : There is an out clause in the document already.  It says that the
primitives are examples and don't necessarily define the actual messages
to be used by the protocol. If you want to do things differently, you
can.

***
15 mins - ANCP Security Threats and Requirements - Hassnaa Moustafa
([email-masked])
http://www.ietf.org/internet-drafts/draft-ietf-ancp-security-
threats-01.txt

Security and authentication/auth per subscriber is out of scope.

Added a block to system diagram for aggregation network.
Also added "regional network".
Considers attacks against multicast use case. Vulnerability analysis
covers cases when Access-node does IGMP snooping or proxying, or relays
message in transactional ANCP.
Multicast scenario attacks in general can be considered similar to
attacks in Use-case 1 and 2.

Major change: On-path attacks, and active attacks.
DoS causing certain subs inability to access certain mcast streams or
reduced bandwidth.
Man-in the middle - forging messages between a NAS and AN.  Message
modification i.e. reducing bandwidth  Message replay.

Asking for comments.
Want to move towards last call.

Woj: How many people read the draft? 2 hands raised.
Woj: Definitely not enough.

Mark: Document goes no where without reviewers. Need 5 volunteers to
read and comment. 
Matthew: Call for volunteers.
Volunteers:
Curtis Sherbo
Phillipe Niger
Michael Busser
Francios LeFaucher
Raymond Zhang

Mark: Can issue last-call and do review during last call.

Woj: Doc covers multicast. Do you see any changes arising out of this
from the multicast discussion currently on-going?

Hassnaa: No. Doc considers multicast from a general perspective and so
all scenarios are addressed.

Matthew Bocci: We'll issue a Last-call mail.

ACTION #4: Chairs  to issue last call for security draft.

***
15 mins - ANCP Protocol Draft - Sanjay Wadhwa
([email-masked])
http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-
01.txt

Not a lot of protocol changes.  Most of the changes were in the form of
adding more clarity to help implementers.

Clarified that draft uses GSMPv3 over TCP.

Protocol implementer just needs to look at RFC 3292 and this draft.

New text for Section 5.
Explicitly specified base GSMPv3 and ANCP message format.

Draft uses just a small subset of RFC 3292 messages - explicitly listed
in the ANCP spec. Additional messages also covered (Bulking of
messages).

Multicast use case will likely result in substantial protocol
development.
Graceful restart and DSL bonding will also require more work. To discuss
on mailing list.

Woj: Sanjay, will you take the action to initiate the discussions on
these two items?
Sanjay: yes

ACTION #5 Sanjay: Initiate WG mailer discussion on graceful restart and
line bonding.

Because graceful restart draft has expired, Sanjay will take action to
discuss graceful restart on mailing list.

Woj: How many people read the draft. 3 hands raised.

Matthew: Comment that we always said draft was for DSL, but it should be
useful for other technologies.  Would like to see a more generic name
for attributes (i.e. not DSL line attributes under DSL Tech type).

Sanjay: Seems like some attributes can indeed be more generic. Needs
more thought.

Woj: Definitely a discussion needed. Draft seems to associate
functionality with tech type attribute.

Sanjay: Sharing of attributes can become cumbersome. Change affects all
tech types.

Matthew will send comment on list.

ACTION #6: Matthew - to send out mail to WG with observations about
protocol draft's use for other technologies.

Samita (from Azaire) : What access technologies are to be covered?

Answer was PON, wireless, etc.  Should be extensible beyond DSL.
However we will focus on DSL as a deliverable right now.

Woj: Charter of the WG makes DSL the primary focus, but intent is to be
extensible to others.

***
30 mins - ANCP Multicast Handling - Roberta Maglione (
[email-masked])
http://www.ietf.org/internet-drafts/draft-maglione-ancp-mcast
-00.txt

Objectives:
Behave like black box, when replication done by AN.
Enable NAS to provide info to AN to allow it to make local decisions
when possible or query the NAS in all other cases.

4 use cases:
  Multicast Conditional Access
  Multicast Admission Control
  Multicast accounting
  Multicast termination

*Multicast Conditional Access
Purpose: To provide network level access control for multicast traffic. 
Two approaches can be taken. The approaches are also specified by MBONED
in multi-aaa framework doc. (policy push and policy pull)

3 scenarios:
1) Decision taken by AN
NAS uses ANCP to provision Access-node
Defines white, black and neither.  White list is the list for which
access-node can make decision without querying NAS. Join requests for
Black list entries are to be denied. All other requests result in a
query to NAS.

2) Decision taken by NAS (or by AAA server) This is a pull model.
Desirable to have decision done by NAS or AAA server in more complex
policy decisions; video conferencing, multi-party access-control, CAC.
Access node is to query to the NAS before allowing a join.

3) Coarse-grained decision by NAS and fine-grained by AN Defines
multicast flow groups.  Multicast flow-group entries share the same
conditional access policy. This will reduce the number of queries to the
NAS.

*Multicast admission control
Objective: Access level admission control for multicast.

Same 3 scenarios as Conditional Access case
1) Admission control by AN
AN pre-provisioned with AC information

2) Admission control by NAS
For Triple Play we want multicast CAC to be synchronized with unicast
CAC.

3) Coarse-grained by NAS and fine-grained by AN Flow-Group means same
bandwidth.  AN performs decisions for flows within same Flow-Group.  NAS
makes admission control decision for whole Flow-Group.

*Multicast accounting
Objective: To have capability for per line time or volume multicast
accounting.

* Multicast termination
Objective: Provide capability to dynamically stop multicast replication
NAS must be able to revoke authorization granted. AN must stop multicast
flow.

Roberta then explained the message flows for each case.

Roberta : Proposal for WG: Incorporate use-cases and requirements in
ANCP framework draft. Message flows in ANCP protocol draft.

Wojciech : Consensus on list is that use cases are plausible.
So are using white and black lists and provisioning.

Discussion on list is whether mechanisms beyond white/black are needed
(i.e. query NAS).

1st question: Resolve framework & requirements document issue, discussed
earlier. Do we want the doc to contain multicast use-case requirements?
Consensus is yes.

2nd question: Would we agree about the optional mechanisms to address
the need for flexibility and/or specific use-cases? Add the primitives
to the requirements doc?

Raymond Zhang : Could white list be considered as a case of black list?
Roberta : No.  Need to query NAS.  Need a third case.

Woj: Issue often discussed is predictability. Pre-provisioned lists
handle well events that are predictable. Cases where predictability is
not possible or feasible, needs reaction when request is issued.

Dong : Still some debates on list. Do we need to query the NAS? For TV
performance requirement needs to be met. Video conferencing may require
application level registration, and authentication. Is IGMP the only
trigger or should there be app layer signaling as the trigger? Prefer to
use single (IGMP?) mechanism for all services. The solution appears to
be complicating not simplifying.

Francois : Not going to be 100% agreement. Everybody agree on
white/black list. A bunch of people want more. Only talking about an
optional mechanism to do more.  Roberta and I think we need that
flexibility. Other people on the list stated so. Toerless, Sanjay and
Curtis want it too. We need flexibility. Also, MBONED defines AAA
multicast; explicitly describe push & pull model for multicast.
Obviously there is more than enough justification.

Mike Mcbride - Agrees. From PIM WG. Read the draft. It seems reasonable
with what we are used to in other IETF mcast groups. Dynamic flexibility
appears to be necessary, and good to have it as option. Supports
proposal.

Hiroshi Ohta : From MBONED. MBONED discussing AAA issues in general
sense, not focusing on access method. Depending on application, but does
definitely see a case for multicast AAA. It is reasonable for framework
& requirement to address multicast handling issues. Yes to first
question. Agrees that flexible option is useful. Yes to second question.

Jeremy : Agree with the NAS making the decision, but why does it require
the query/pull mechanism?  Why can't all IGMP messages go up to NAS (the
transparent snooping case)?  If transparent snooping is used, won't
there be two messages going to the NAS (query and IGMP).

Roberta : There is a common assumption that the AN is acting as an IGMP
proxy not transparent snooping.

Jeremy : If so, we need to explicitly note that either 1) transparent
snooping is not used 2) it won't work or that 3) we don't want to rely
on IGMP between the AN.

Mark : In one case IGMP comes up. ANCP is involved to send to the NAS.
In the other case, IGMP is sent all the way to the NAS. Seem to be very
similar. This kind of detail can be for later.

Francois : Perhaps terminology is a problem. Key point: Is the decision
entirely taken by the AN or not? We're saying that there is a case when
the NAS decides. Doesn?t matter too much for the current discussion
whether the NAS decides following ANCP or IGMP.

Jeremy : But ANCP requires a specific message.

Francois : correct. But bigger question is: Do we agree that NAS makes
the decision?

Sanjay: Agree.

Woj: We can have the debate about IGMP trigger or not, but we don't have
control over existing IGMP implementations and optimizations. Within
ANCP we can introduce own optimizations.
Key take away from discussion: There is agreement that ANCP needs to
support scenarios where NAS takes the multicast decision.

Sanjay: For CAC, the mainstream scenario is for NAS to take decision.
Does it make sense to have a grey list?

Francois: Initial proposal actual included Grey list. Then it was
removed because wed hoped to achieve same thing with masks & ranges. But
can now see a case where grey list would help. We need to think more and
perhaps to add grey lists.

Dong : Question on slide 8. Seems to see performance problems with
query.

Woj: Two proposals on the table. One says "white&black", other says
"white&black + query". Are you saying that we shouldn't discuss the
latter? 

Dong: Need to understand how mechanism works.

Woj: Let's take a step back. Do you agree on the CAC use-case? Some of
the valid deployment options are to have CAC done by AN, some by NAS.
Within the scope of ANCP WG, we deal with what happens between NAS and
AN. The use-case here is about CAC done by NAS. Query makes this happen.

Dong: Still not clear how query can be used to support use-case.
Performance concerns.

Curtis Sherbo: Draft proposes white/black lists ? these can be used
where performance matters. In other cases when choosing to use
conditional access, SPs would knowingly choose the mechanism and be
aware of its performance. 

Dong: Don't see the mechanism in the draft support the scenario you
mention.

Sanjay: In practical cases, grouping of flows do not result in query per
zap. Specific case can be thought of as resulting in query per zap.

Mark : Centralized and distributed databases scale in different ways.
This is a classic problem. Depends on which you want to optimize. Each
has tradeoffs. Centralized slower to access, easier to manage. The
mechanism offers operator the choice.

Ulf Borinad (Operax) : Clarification question on managing lists. If
something doesn?t exist on white/black, it should result in a query. Is
the list then updated?

Francois: That's a possibility allowed by the proposal.

Woj : We have specific proposal in this draft. Mark how do you propose
handling it?

Mark : As AD I see far more support for flexibility for query mechanism
than not in this room. So I don't see any justification to not support
that flexibility. Needs to be confirmed on mailing list.

Woj: Take flexibility as key thing. Lot of support, individual
opposition.

ACTION #7: Chairs - confirm multicast direction on list.

***
15 mins - Extension of ANCP for Satellite and Terrestrial Wireless Modem
Networks - Lloyd Wood ([email-masked])
http://www.ietf.org/internet-drafts/draft-floreani-ancp-
wireless-00

Been dealing with problem with which ANCP can help
Smart adaptive modems need to update routers with current satellite
modem speed. Similar to DSL.

Looking at adding wireless class extension to ANCP.

Point-multipoint and point-point cases. Eventually moving to point to
point.

Use ethernet between modem and router because of cost. Serial would be
best option, but not going to happen.

ANCP works across TCP. Given that satellite delay is an issue, doing
ANCP local looks like the answer.

Multicast CAC use-case also of interest to satellite.

Interested in comments and whether this is something for ANCP.

Francois : Seems to match what ANCP does.  But isn't it overkill to use
GSMP based protocol just to sync line rate?

Lloyd : This may be overkill, but we have working code and it will work.
Just software. However a lot of framework is not used. But in deployment
scenarios the fuller framework may get used to cover other access types.

Sanjay: ANCP between NAS and modem - ok. But ANCP between CPE and modem
raises questions. Is CPE trusted device? ANCP is typically contained to
trusted domain

Discussion on managed CPE options. Are CPE and NAS operated by different
companies.

Lloyd: Depends on provider. 50/50 case in satellite industry; some
provide router+modem, others only modem.

Lloyd: Modems turning to L3 device, part of the problem. Is ANCP
suitable.

Woj: Do you have specific issues with the protocol spec for satellite
use?

Lloyd: ANCP is an overkill, but it has all we need. Fine for our use.

More discussion on CPE side aspect of modem and router.
In DSL case there appears to be the same problem on the home side,
between router and modem. Problem seems to be applicable to DSL too.

Woj: So far we focused on the service provider side, not the home. Home
is an un-explored area for us.

Wojciech : Broader question is how do we ensure extensibility of ANCP to
other technologies?  Current text protocol spec to be very DSL tech type
centric. Need to decouple function from tech type so that it can be
re-used by other tech types.
Also need to define extensibility path for TLVs.

Sanjay: For each tech type do we need enumerate the TLVs?

Woj: No.

Usual search for blue sheets...

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