Subject: [ANCP] Vancouver minutes

From: "BOCCI Matthew" <[email-masked]>
Date: Wed, 2 Jan 2008 14:31:32 +0100

Please find attached the draft minutes from Vancouver.

Please let me know if you have any comments by Friday 4th Jan.

Many thanks to Curtis for taking the notes.

Regards,

Matthew

Thursday, December 6th, 2007 - 13:00 - 15:00
-----------------------------------
CHAIRS: Wojciech Dec (Absent) & Matthew Bocci
SCRIBE: Curtis Sherbo

WG Status and Update - Chairs
-------------------------------------
Milestones:
Security threats review, only 4 of 5 responses received
Sanjay Wadhwa: proposed delaying MIB last call since protocol work is
ongoing, Matthew agreed

Protocol draft:
Chairs have asked a small design team to produce text for protocol
extensions and/or modification of requirements of multicast control
Ensure protocol meets the requirements/framework
Implement comments for the list
Target of march 08
Francois Le Faucheur: Agree with proposal, would like a couple of
iterations of progress for comment. Agreed. Design team will produce
iterations for review on WG list.
Design team: Roberta Maglione, Stefaan De Cnodder, Sanjay Wadhwa,
Philippe Champagne

ANCP gaps from WT 147 liaison from DSLF:

Topology Discovery
-Access node uplink
Access port configuration
-Configuration of parameters beyond the dsl modem traint rate, eg. acls,
vlan assignment, .1p mapping parameters, policer
-Opening and closing of access loop
Multicast
-Assignment of multicast vlan
-Periodic membership reporting
Other gaps from wg alias
Link bundling (Bonding)

NAS MIB:
Francois Le Faucher: Topology discovery link from the NAS, thinks it is
important
Stefaan de Cnodder: NAS MIB is planned, but further out
Sanjay Wadhwa: Assignment of mcast vlan is important for wholesale
Mark Townsley: 147 is a set of requirements from DSLF for L2CP. What is
the opinion of the industry how to solve these problems? No answer.
Stefaan de Cnodder: Link bundling question, link bonding on dsl line,
added to protocol, but not yet in framework
Mark Townsley: what do we do about gaps? Need these items formulated a
bit better to understand them.
Matthew noted what has been supported by attendees
Mark Townsley: We should track these gaps, and not proceed until they
are addressed.
Action: take to list
Matthew; additionally, some extensibility guidelines should also be laid
down
e.g. vendor specific code space
Matthew, suggest design team tackle these and come up with a proposal
Peter Arberg, vendor specific attribute capability, draft on the list
after the meeting

ANCP Framework and Requirements - Stefaan de Cnodder
([email-masked])
http://tools.ietf.org/html/draft-ietf-ancp-framework-04
--------------------------------------------------------
History: 04 is the latest version
Version 3: multicast use case updated, bonding, notify NAS of access
loop configuration change due to EMS.
04 changes: small terminology consistency change ("net data rate")

New sections:
Section 3 use case multicast
Section 4 requirements, multicast security
Definitions update in section 1.2
Reference architecture two new messages, admission requests and
admission response
Use case conditional acceess
Admission control
Accounting
Termination
Sanjay Wadhwa: Third option of admission control discussed on list, IGMP
from routed gateway to NAS direct, NAS decide and asynchronous message
to access node. Agreed should be included as third option
Sanjay Wadhwa: Same comment for accounting
Next steps - update based on comments
Francois le Faucher: The max number of entries in list was put in doc
prematurely, Sven sent to list, one comment, received. Should go to list
for more support, minimum threshold, 
Matthew doesn't want it removed, then discussed, want it discussed
first, then decide what to do,
Matthew will raise on list again. 
Francois:  Criteria to keep it in need to be more than "no one objects".
If no one cares, then it should be off.

Multicast Issues - Roberta Maglione ([email-masked])
http://tools.ietf.org/html/draft-ietf-ancp-framework-04
http://tools.ietf.org/wg/ancp/draft-maglione-ancp-mcast-00.txt
--------------------------------------------------------------
Grey list and default behaviour
Spontaneous admission response
Grey list to reduce NAS load according to WG discussion in Chicago
A grey list identifies the multicast flows for which the access node can
join before queries for further authorization
What does wg prefer for default behaviour for a join that does not match
any list: deny, allow ?
Operator can override with wildcard
General case is where ANCP not used to convey join /leave
Detailed changes title 3.4.4 
Use case in 3.4.4
Add modifications related requirement in section 4.2
Accounting
Enhance multicast accounting section
NAS preference to time and /or volume accounting is needed
For mcast flows controlled by NAS (GreyList) at time of message sent to
an
For mcast flows controlled by access node white list can convey NAS
during white list provision phase
information report message used by an to communicate accounting
information to the NAS
AN can consolidate multiple sets of accounting information inside a
single ancp message to reduce the number of information report messages
sent from the an to the NAS
Detailed changed modify use case 3.4.3
add/modify requirements
multicast reporting 
add capability for NAS to query the an to obtain instantaneous report
status relate to multicast flows currently replicated by the an
such a reporting function could be useful for troubleshooting and
monitoring purposes
three different types of report-query
port report query
multicast flow report query
an global report query

detail replace 3.4.3 title
add use case 3.4.3
requirement s4.2, 4.7.6 and 4.8.6

Stefaan de Cnodder, comment on default behavior, missing option accept
on best effort basis
Francois le Faucher: discussion started on list, more discussion to
occur, assume that particular mcast, to that particular port ? to
Stefaan
Stefaan de Cnodder, don't do any BW admission control, queue in switch,
just do best effort
Francois le Faucher: question will you always send high priority before
the best effort? 
Stefaan: depends on the Marking
Francois le Faucher, who is remarking
Toerless: There is a difference between allow and best effort
Stefaan de Cnodder: allowed if best effort, if there is enough BW, check
if sub has subscription, 
Francois : response to an for access control, based on bw, suspect that
is not what Sven meant
Stefaan, just want third option covered
Peter  color names confusing, support Stefaans proposal to be one list,
change names to permit deny query
Sanjay Wadhwa, nas send only whitelist, assume all the rest, traverse
lists
Peter, if keep as three lists, need priority of lists, should be one
list with no priority, 
Toerless, means ordered list, does this mean more than three lists
Peter, not same thing, should be like an access list in a router,
ordered list, first match behaviour
Toerless, if separate lists, using priority is same behaviour, how much
complexity should be allowed, should be three lists, for interop without
differing definitions across vendors, 
Peter, agree that if lists, need priority
Sanjay Wadhwa, logical single list, an could do three best match
lookups, another default action should be query nas
Francois le faucher, comment on, keep definition as is in requirement
doc, it is understood, protocol should define it, agreement and
resolution in protocol document,
wrt to default behaviour, default default, needs decision, directed
towards Sanjay Wadhwa, query default. Agreement; there needs to be a
default-default (when nothing is configured) and a configurable default.
That latter can be allow/deny/query.
Stefaan, comment on reporting, port report query, support, maybe not
agree on all attributes, concern how many (timestamps) need to be
tracked by an global reporting, too much information, might not fit in
gsmp
Toerless, how does report relate to graceful restart
Stefaan, question for Toerless, does it mean the acls, align state of an
with nas, not sure if this is good idea, needs to be examined in
graceful restart
Francois le Faucher, question, clear cases where nas has time based
info, volume info, cases both, therefore maybe nas tell an do volume
based acct or time based, question is that useful, or is easier for an
to always maintain and report both?
Stefaan, understand an sends start and stop to nas,
Francois le Faucher, an give all info when queried
Stefaan, an not counting packets, nas counts bytes, an tells nas to
start counting
Toerless, packet counting, no sync between forwarding and signalling, an
already replicating before nas receives message, question of accuracy
Stefaan, also unicast, sends sync rate, line down, packets lost,
accounting already done on NAS, no different
Toerless, are you saying it won't work well, but compatible with unicast
Sanjay Wadhwa NAS might not be in data path
Toerless, does dslf require AN to count packets, if an does, then why
not mcast
Stefaan, not sure, but believes motivation for ancp was to do it in a
centralized way
Francois le Faucher, current text does not reflect this behaviour;
assumption is that AN can count packets.
Matthew, discusion needed on list

ANCP Access Node MIB - Stefaan de Cnodder
([email-masked])
http://tools.ietf.org/html/draft-ietf-ancp-mib-an-01
--------------------------------------------------------
01 submitted in November
00 changes:
partitioning, added a scalar to configure wherher partitions are used or
not
interface config table
notifications, up and down notifications can be enabled/disabled per
session
modifiying attributes
01 session index 
ip address 
port number configuration possible

ANCP Security Threats - Hassnaa Moustafa
([email-masked])
http://tools.ietf.org/html/draft-ietf-ancp-security-threats-03
-----------------------------------------------------------------
WG LC in October
Version 3 as a result
Changes, editorial, acknowledgment, admin domain clarification,
potential, attacks against ancp clarifing text, multicast use-case
added, security requirements updated
Matthew, last meeting, discussed waiting for framework to complete
before sending security to iesg, send both together
Hasanna, to keep alive, submit a new version, 
Matthew, any more comments can be considered part of previous last call
Mark Townsley: when do framework last call, redo last call on security

ANCP Protocol Draft - Sanjay Wadhwa ([email-masked])
http://tools.ietf.org/html/draft-ietf-ancp-protocol-01
Discuss protocol draft updates and ANCP graceful restart.
----------------------------------------------------------
consistency with framework
new section 2.1 on terminology
net data rate used
new multipair bonding text
text for topology discovery extensions 5.4.2
clarified message format in line configuration extension, section 5.4.3
concern over tlv changes, diverges from tr-101 and rfc 4679 in TLV#.
Common notion is for BRAS to pass TLV transparently into Radius. Changes
held back. Doesn't see issue as colliding values have been changed
previously.
access loop remote id and sub tlv access loop encapsulation
suggest not deprecate these tlvs, keep them alive
Peter, why did Woj want this deprecated, agrees that these shouldn't be
deprecated. 
Sanjay, reason was to depreciate to avoid overlap, but ROI is small in
this case.
graceful restart draft updated, support for multicast use cased agreed
upon by the WG.
Matthew, should graceful restart be a separate draft going forward,
Sanjay agreed
Matthew, graceful restart not on charter, need to add to milestones

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

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 2 Jan 2008 15:01:26 +0100

Hello Matthew,

Small suggestions:

Regarding:
> Stefaan de Cnodder, don't do any BW admission control, queue in  
> switch, just do best effort
> Francois le Faucher: question will you always send high priority  
> before the best effort?
> Stefaan de Cnodder: allowed if best effort, if there is enough BW,  
> check if sub has subscription,
> Francois : response to an for access control, based on bw, suspect  
> that is not what Sven meant
I think the conclusion was that the notion of "admit as best effort"  
was not well defined and was interpreted differently by different  
people. Hence, I believe the plan was to have this notion discussed  
on the list first (in particular to get from Sven a description of  
how he understood it in his proposal).

Also please s/Le Faucher/Le Faucheur/ in a few places.

Thanks

Francois

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 4 Jan 2008 12:08:45 +0100

Hi Folks,
 
the Vancouver meeting saw some renewed discussions regarding TLV
changes. 
For the record I will (once again) provide the reasons why this problem
needs to be addressed (whether through depreciation or other means). The
problem is likely to cause interoperability problems with any new ANCP
implementations.

The options as I see it are (if there are others, lets hear them):

1a. Do not depreciate TLVs, and assume that all implementations and
users will follow the latest ANCP draft (i.e. assume that draft-l2cp
problems never happened).
1b. Do not depreciate TLVs, but introduce a "known caveats" in the
appendix of the protocol draft, describing the potential legacy
implementation interoperability problem.
2. Depreciate TLVs.

Now, given that option 2 appears to have just recently been presented
with a reasonable argument against it (see Vancouver minutes below), I
call for the WG to decide on 1a or 1b. 

Some background:

The problem was introduced in edits made between pre-ANCP WG drafts to
draft-wadhwa-gsmp-l2control-configuration-00. 
Version 00 of this draft dated August 2, 2005 saw the PORT-UP message
TLV 0x02 assigned to "Access-Aggregation-Circuit-ID-Binary". The next
version 01, dated September 2006, saw the same TLV assigned to
"Access-Loop-Remote-Id".
A similar story applies to PORT-UP TLV 0x04 sub-TLV 0x90, which saw it's
meaning changed between drafts. The ANCP protocol draft is derived from
the 01 version.

It so happens however that most known implementations are based on the
00 draft, which presents an interoperability problem to anyone who
implemented the 00 definition and those that implement the latest ANCP
draft. Hacks aside, a long term fix needs to be devised. 
NOTE: There is no known way to distinguish l2cp draft 00, 01 or ANCP
draft speakers other than trough hacks, which current 00 implementations
are known to have adopted as a "workaround" to *ONE* of the problem.

Now the original proposal of a solution was drafted in
http://www1.ietf.org/mail-archive/web/ancp/current/msg00152.html and the
WG provided no objections. Furthermore the topic was also discussed
during IETF 69 back in March 2007 (minutes here:
http://tools.ietf.org/wg/ancp/minutes?item=minutes68.html). Again no
objections were raised by any of the WG participants.
Hence the decision to *depreciate* conflicting TLVs was previously made
by the WG (and claims of this being otherwise are removed from the
truth). 

---snip---
 
<http://tools.ietf.org/html/draft-ietf-ancp-protocol-01>  

	access loop remote id and sub tlv access loop encapsulation 
	suggest not deprecate these tlvs, keep them alive 
	Peter, why did Woj want this deprecated, agrees that these
shouldn't be deprecated. 
	Sanjay, reason was to depreciate to avoid overlap, but ROI is
small in this case. 
	graceful restart draft updated, support for multicast use cased
agreed upon by the WG. 
	Matthew, should graceful restart be a separate draft going
forward, Sanjay agreed 
	Matthew, graceful restart not on charter, need to add to
milestones 

---snip--

Regards,
Woj.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 4 Jan 2008 12:10:59 +0100

Hi Folks,

Some background:

---snip---

---snip--

Regards,
Woj.

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Mon, 07 Jan 2008 15:06:49 +0100

> problems never happened).

You cannot assume that.

> implementation interoperability problem.

Important changes that may lead to interop issues when implementations 
implement different versions of the same draft should be documented 
properly in the appendix.  But this should be avoided as much as 
possible...  Maybe it should be looked at case by case.  If a number 
changes of a TLV that is not important, then it will not harm a lot, but 
if it happens to important TLVs like the ones carrying bandwidth or 
ACIs, then it should be avoided and if not possible to avoid, describe 
it very well in the appendix.

regards,
Stefaan

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 7 Jan 2008 15:18:06 +0100

Stefaan, are you behind option 1b then?

The case if currently for :

PORT-UP message TLV Type 0x02
PORT-UP message TLV 0x04 sub-TLV 0x90

Both of which I beleive are currenly implemented (based on the
conflicting definition in draft-wadhwa-00).

BTW. I naturally meant depricate not depreciate ;-)

-Woj.

> -----Original Message-----
> From: Stefaan DE CNODDER 
> [mailto:[email-masked]] 
> Sent: 07 January 2008 15:07
> To: Wojciech Dec (wdec)
> Cc: [email-masked]
> Subject: Re: [ANCP] Depreciation of TLVs ... again
> 
> 
> 
> > 
> Important changes that may lead to interop issues when 
> implementations implement different versions of the same 
> draft should be documented properly in the appendix.  But 
> this should be avoided as much as possible...  Maybe it 
> should be looked at case by case.  If a number changes of a 
> TLV that is not important, then it will not harm a lot, but 
> if it happens to important TLVs like the ones carrying 
> bandwidth or ACIs, then it should be avoided and if not 
> possible to avoid, describe it very well in the appendix.
> 
> regards,
> Stefaan
> 
> 
> > 2. Depreciate TLVs.
> > 
> > TLV 0x02 assigned to 
> "Access-Aggregation-Circuit-ID-Binary". The next 
> > A similar story applies to PORT-UP TLV 0x04 sub-TLV 0x90, which saw 
> > it's meaning changed between drafts. The ANCP protocol draft is 
> > derived from the 01 version.
> > 
> > draft speakers other than trough hacks, which current 00 
> > implementations are known to have adopted as a "workaround" 
> to *ONE* of the problem.
> > 
> http://www1.ietf.org/mail-archive/web/ancp/current/msg00152.html and 
> > the WG provided no objections. Furthermore the topic was also 
> > discussed during IETF 69 back in March 2007 (minutes here:
> > Hence the decision to *depreciate* conflicting TLVs was previously 
> > made by the WG (and claims of this being otherwise are removed from 
> > the truth).
> > 
> >  
> > ---snip---
> >  
> > text for topology discovery extensions 5.4.2 clarified 
> message format 
> > in line configuration extension, section 5.4.3 concern over tlv 
> > changes, diverges from tr-101 and rfc 4679 in TLV#.
> > Common notion is for BRAS to pass TLV transparently into Radius. 
> > Changes held back. Doesn't see issue as colliding values have been 
> > changed previously.
> > 
> > 	Peter, why did Woj want this deprecated, agrees that 
> these shouldn't 
> > be deprecated.
> > 	Sanjay, reason was to depreciate to avoid overlap, but 
> ROI is small 
> > in this case.

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Mon, 07 Jan 2008 15:49:45 +0100

Woj,

Let's say that I am against 1a.  It also requires that all ANs and all 
NASes are upgraded at the same time which is unlikely.

It depends on which node is typically upgraded first.  Are ISPs first 
upgrading the NAS or first the AN?  I would expect first the NAS.  If 
that's true, then it looks to me that it should be like this:

If I see correctly "PORT-UP message TLV Type 0x02" changed meaning and 
the original data that was in TLV 0x02 is now in 0x06.  However, this is 
an optional TLV and does not look that important, and to avoid interop 
problems, a NAS should not interprete TLV 0x02 "for some time", except 
in displaying this information or other things that does not break the 
correct operation of ANCP.  This until we are sure that there are no 
implementations that use the old spec.  This should be described in an 
appendix of the draft.

subTLV 0x90 is renumbered to 0x91.  Here the BRAS should, to avoid 
interop problems, interprete both 0x90 and 0x91 in the same way.  If 
both are there, then only 0x91 should be interpreted.  Also this should 
be described clearly in the appendix.

In the future it would be better that the numbering is kept as it is. 
For instance, for TLV 0x02 it should never have been moved to 0x06 and 
then using 0x02 for something else...  This could have been avoided, but 
if it cannot be avoided, then it should be described explicetely in the 
appendix.

regards,
Stefaan

Wojciech Dec (wdec) wrote:

>>>users will follow the latest ANCP draft (i.e. assume that 
>>
>>draft-l2cp 
>>
>>>Now, given that option 2 appears to have just recently been 
>>
>>presented 
>>
>>>with a reasonable argument against it (see Vancouver 
>>
>>minutes below), I 
>>
>>>The problem was introduced in edits made between pre-ANCP 
>>
>>WG drafts to 
>>
>>>Version 00 of this draft dated August 2, 2005 saw the 
>>
>>PORT-UP message 
>>
>>>TLV 0x02 assigned to 
>>
>>>It so happens however that most known implementations are 
>>
>>based on the 
>>
>>>implemented the 00 definition and those that implement the 
>>
>>latest ANCP 
>>
>>>NOTE: There is no known way to distinguish l2cp draft 00, 
>>
>>01 or ANCP 
>>
>>>http://tools.ietf.org/wg/ancp/minutes?item=minutes68.html). 
>>
>>Again no 
>>
>>>	Matthew, should graceful restart be a separate draft 
>>
>>going forward, 
>>
>>>Sanjay agreed
>>>	Matthew, graceful restart not on charter, need to add 
>>
>>to milestones
>>
>>>---snip--
>>>
>>>Regards,
>>>Woj.
>>>
>>>

---

From: "Haag, T" <[email-masked]>
Date: Mon, 7 Jan 2008 23:32:49 +0100

Hi Woj,

Thanks for bringing up this issue.

>From an operator's point of view which currently runs L2C implementation in large scale network option 1a is not acceptable at all.

Option 1b as compromise is helpful to point out interoperability problems although option 2 fits best in current running L2C implementations in large scale networks in conjunction with version control. 

The need for version control was discussed several times to find acceptance.
The options you address show to me that the need for version control is always present although IETF WG discussions have shown a different view. 

Regards
Thomas Haag
 
T-Systems Enterprise Services GmbH
Systems Integration

-----Ursprüngliche Nachricht-----
Von: Wojciech Dec (wdec) [mailto:[email-masked]] 
Gesendet: Freitag, 4. Januar 2008 12:11
An: [email-masked]
Betreff: [ANCP] Depreciation of TLVs ... again

Hi Folks,

Some background:

---snip---

---snip--

Regards,
Woj.

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 08 Jan 2008 05:35:28 -0800

If a change in a TLV or the addition of a new TLV
will cause incorrect operation in a receiver that
implements a previous version of the protocol, then
the new version requires a new version number.

Then the version negotiation can be used to avoid
the incorrect operation in case not all peers
support the new version.

I do not understand the reluctance to bump version
numbers. There is enough number space to accommodate
the most trivial changes.

Stefaan DE CNODDER wrote:
>>> [mailto:[email-masked]] Sent: 07 January 2008 
>>> 15:07
>>> To: Wojciech Dec (wdec)
>>> Cc: [email-masked]
>>> implementations implement different versions of the same draft should 
>>> be documented properly in the appendix.  But this should be avoided 
>>> as much as possible...  Maybe it should be looked at case by case.  
>>> If a number changes of a TLV that is not important, then it will not 
>>> harm a lot, but if it happens to important TLVs like the ones 
>>> carrying bandwidth or ACIs, then it should be avoided and if not 
>>>>     suggest not deprecate these tlvs, keep them alive     Peter, why 
>>>> did Woj want this deprecated, agrees that 
>>>
>>> these shouldn't
>>>> be deprecated.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 8 Jan 2008 15:03:29 +0100

Previously posted versioning strategy accepted by the WG:

--snip--
The conclusion that we reached is that any protocol version or
sub-version change are to be done primarily to address substantial
protocol changes that will render previous versions incompatible - this
is best practice, besides common sense that is used throughout the IETF
community. It will be for the WG group, backed by technical advice when
required, to decide when this stage is actually reached.

In view of our WG's chartered work, such a stage may actually come
towards the end of the protocol specification where we could, for
example decide to use a modified protocol state-machine, protocol
transport, and/or transport port.

The following list is deemed to not qualify as substantial protocol
changes, and thus will not be considered as sufficient ground for
changing/revising the ANCP version, or sub-version number:

i) a new revision of the protocol spec*
ii) a conflicting TLV or sub-TLVs
iii) incompatibilities arising from implementations of pre-RFC drafts.
iv) new negotiable protocol capabilities (eg Bulk message capability)

* Unless the revised draft diverges so far in protocol compatibility
from its origin as to render it incompatible, for example a new protocol
RFC

If and when the WG agrees that substantial changes have been made to the
protocol, a new protocol version will require an IANA version registry
change. 

--snip---

The problem in this case is that the known problems stem from pre-RFC
draft implementations, and even if doing a version change, any deployed
"pre ANCP draft" devices would be rendered incompatible unless one
introduced in the "next version draft" clauses about backwards
compatibility to "pre-rfc" implementations - this is an oxymoron. 
That said, if the WG is ready to agree and bite the bullet in
versioning-up, that option is also possible, but for the reasons above
(shouldn't have an RFC dictating backward compatibility to a pre-RFC
implementation) not trivial.

-Woj.

> From: Jakob Heitz [mailto:[email-masked]] 
> Sent: 08 January 2008 14:35
> To: [email-masked]
> If a change in a TLV or the addition of a new TLV will cause 
> incorrect operation in a receiver that implements a previous 
> version of the protocol, then the new version requires a new 
> version number.
> 
> Then the version negotiation can be used to avoid the 
> incorrect operation in case not all peers support the new version.
> 
> I do not understand the reluctance to bump version numbers. 
> There is enough number space to accommodate the most trivial changes.
> 
> > the original data that was in TLV 0x02 is now in 0x06.  
> However, this 
> > is an optional TLV and does not look that important, and to avoid 
> > interop problems, a NAS should not interprete TLV 0x02 "for some 
> > time", except in displaying this information or other 
> things that does 
> > not break the correct operation of ANCP.  This until we are 
> sure that 
> > there are no implementations that use the old spec.  This should be 
> > described in an appendix of the draft.
> > 
> > both are there, then only 0x91 should be interpreted.  Also this 
> > should be described clearly in the appendix.
> > 
> > then using 0x02 for something else...  This could have been 
> avoided, 
> > but if it cannot be avoided, then it should be described 
> explicetely 
> > in the appendix.
> > 
> > regards,
> > Stefaan
> > 
> > 
> >>> implementations implement different versions of the same draft 
> >>> should be documented properly in the appendix.  But this 
> should be 
> >>> avoided as much as possible...  Maybe it should be looked 
> at case by case.
>  Peter, why

---

From: "OOGHE Sven" <[email-masked]>
Date: Tue, 8 Jan 2008 16:02:52 +0100

Hi,

In the Vancouver meeting minutes there is mention about multicast
bandwidth admission control, and what to do with "best effort" streams.
Apparently there is some confusion on the concept. This email is the
clarify my view on this.

As already described in section 3.4.2, there is a need - next to policy
based admission control - to perform CAC for the video content being
streamed across the access network. The different options to do so are
already defined in the framework document.

Now, the point I wanted to bring up is that in general, the Access Node
and NAS cannot be aware of all possible multicast groups. It is likely
that there may be multicast channels offered across the Internet. For
these streams, performing bandwidth admission control may be
challenging.

To solve this, these requests should by default be accepted, but the
network should handle the traffic as best effort. This can be done by
first of all adding a "catch-all statement" in the Access Node white
list or grey list. In case the Access Node queries the NAS, the NAS on
his turn will have to accept the request. That way, the unknown streams
are not blocked by default. Next, the NAS must make sure that the
multicast content coming from the Internet is marked as best effort
traffic. This way, whenever congestion occurs somewhere in the
access/aggregation network, this stream will be kicked out before the
access provider's own premium content.

If people agree with this, I suggest to add the above discussion to the
framework document.

Regards,
Sven

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 14 Jan 2008 13:05:41 +0100

Hi Sven,

Thanks for the clarification.
The approach you describe below seems fine to me.
I think the key point it brings is to clarify that it it can make  
sense to perform CAC on some flows and not on others (and the non- 
CACed flows will not break the CACed flows).

One small point. When you say "the NAS must make sure that the  
multicast content is marked as best-effort", I wasn't sure if you  
implied that the NAS would remark the flow. While that may be an  
option, a more common case if probably that the flow got marked best- 
effort somewhere upstream (eg when flow enters the SP network). I  
think it would be worth clarifying.

Also, I would suggest that the text uses "Internet/Unkown" channels  
just as an example of where this sort of approach may be used, but  
make it clear it is a generic capability (e.g. the best-effort  
approach can be used on known flows also).

Cheers

Francois

---

From: "OOGHE Sven" <[email-masked]>
Date: Mon, 14 Jan 2008 16:42:43 +0100

Hi Francois,

see inline. 

Regards,
Sven

-----Original Message-----
From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: maandag 14 januari 2008 13:06
To: OOGHE Sven
Cc: Francois Le Faucheur IMAP; [email-masked]
Subject: Re: [ANCP] Multicast BW Admission Control

Hi Sven,

Thanks for the clarification.
The approach you describe below seems fine to me.
I think the key point it brings is to clarify that it it can make sense
to perform CAC on some flows and not on others (and the non- CACed flows
will not break the CACed flows).

<Sven>Yes, I agree with this</Sven>

One small point. When you say "the NAS must make sure that the multicast
content is marked as best-effort", I wasn't sure if you implied that the
NAS would remark the flow. While that may be an option, a more common
case if probably that the flow got marked best- effort somewhere
upstream (eg when flow enters the SP network). I think it would be worth
clarifying.

<Sven>Correct, this is what I meant. In my rationale the NAS was the
entry point of the service provider network. But indeed, that may well
be another node</Sven>

Also, I would suggest that the text uses "Internet/Unkown" channels just
as an example of where this sort of approach may be used, but make it
clear it is a generic capability (e.g. the best-effort approach can be
used on known flows also).

<Sven>I am working on an updated framework version, which will include
the above notion for both known and unknown streams.</Sven>

Cheers

Francois

On 8 Jan 2008, at 16:02, OOGHE Sven wrote:

> As already described in section 3.4.2, there is a need - next to 
> policy based admission control - to perform CAC for the video content 
> being streamed across the access network. The different options to do 
> so are already defined in the framework document.
>
> Now, the point I wanted to bring up is that in general, the Access 
> Node and NAS cannot be aware of all possible multicast groups. It is 
> likely that there may be multicast channels offered across the 
> Internet. For these streams, performing bandwidth admission control 
> may be challenging.
>

> his turn will have to accept the request. That way, the unknown 
> streams are not blocked by default. Next, the NAS must make sure that 
> the multicast content coming from the Internet is marked as best 
> effort traffic. This way, whenever congestion occurs somewhere in the 
> If people agree with this, I suggest to add the above discussion to 
> the framework document.
>
> Regards,
> Sven
>
>

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Tue, 15 Jan 2008 14:31:18 +0100

Hi Sven, Francois,

see below...

> will not break the CACed flows).

How do I have interprete this CAC?  From the email discussion I 
understand that the AN will not do any CAC on joins not matching with 
any white/grey/black list, assuming that this is an Internet multicast 
flow marked as best effort somewhere by an edge router.  Then I 
understand that when the join matches a grey list, then all checks 
including the bandwidth CAC checks are perfomed in the NAS, and when it 
matches a white list, the NAS is not queried and hence the AN is doing 
all the checks.  This is then done without querying the NAS, but still 
under control by the NAS, i.e., the NAS configures the AN via ANCP such 
that the AN can do all the checks.  The latter means that the NAS must 
provision the AN with the necessary information to let the AN to make 
the decisions: in a white list the NAS configures the multicast groups 
(with masks), sources, bandwidth, and possibly other information (e.g., 
related to accounting).

If this is what we all understand, then it looks good.

regards,
Stefaan

> effort somewhere upstream (eg when flow enters the SP network). I  think 
> it would be worth clarifying.
> 
> just as an example of where this sort of approach may be used, but  make 
> it clear it is a generic capability (e.g. the best-effort  approach can 
> be used on known flows also).
> 
> Cheers
> 
> Francois
>

---

From: "Busser, M" <[email-masked]>
Date: Wed, 16 Jan 2008 08:32:19 +0100

All.

I fully agree with Stefaan.
We can not assume 1a, so i am aganinst it.

I also think, that TLV Type 0x02 is not that important. It is also an optional TLV. 
So ignoring it for a while at the NAS as Stefaan suggests is an acceptable solution for me.
It it also not used by RAM or OAM at the moment (as far as I know), so we shouldn't have problems with that.

With subTLV 0x90 renumbered to 0x91, we can proceed as follows: 

Lets assume, we have a AN running with an "old" version of the draft (e.g. Dec. 2005). 
Those systems will never send a subTLV 0x91. If the NAS receives a subTLV 0x90, 
it should interpret this subTLV as DSL-Type.

If we have a AN running a later version of the draft, the NAS will at least receive a 
subTLV 0x91 because this is mandatory. It may also receive a subTLV 0x90, wich is optional. 
In this case, the NAS should interpret 0x90 as Access-Loop-Encapsulation and 0x91 as DSL-Type.

The only thing, we have to take care of is that the NAS have to be updated to this behaviour first. 
After that, the AN vendors can change their implementations whenever the want.

I also agree with Stefaan, that we schould describe this in detail in an appendix. 
The other changes we made, concerns the length of some parameters. This can be solved by the AN vendors, 
as long as we have different implementations at the NAS side in that specific detail.
This is actually already the case as far as i know.

I think, 1b is the way to go.

Some other useful information for a "known caveats" appendix:

OAM-Loopback-Test-Parameter=0x07
The length of the parameter has changed from 8 to 4 bytes.
Depending on the implementation at the NAS, a AN can receive the OAM-Loopback-Test-Parameter with length=8 as well as with length=4 byte.
AN vendors should take this into account.

The other way of course is to have a kind of a version number wich is our preference.
But even if the group decide to have an ANCP version number, we need
an agreement, how to proceed from the actually running implementations. 

Best Regards

Michael Busser

-----Ursprüngliche Nachricht-----
Von: Stefaan DE CNODDER [mailto:[email-masked]] 
Gesendet: Montag, 7. Januar 2008 15:50
An: Wojciech Dec (wdec)
Cc: [email-masked]
Betreff: Re: [ANCP] Depreciation of TLVs ... again

Woj,

regards,
Stefaan

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 16 Jan 2008 07:18:05 -0800

Stefann,

I am a bit confused about the Cc'ed and your prior mail, because i
think they contradict each other. Aka:

a) In the first mail i thought to understood that you wanted a
   usage case of internet video for which no admission control is done,
   and because there may be other video traffic for which admission
   control IS done, the idea is to have the non-CACed video use simply
   "best-effort" DSCP marking. 
   
   Correct ?
   
   So, then i conclude that

    I) this "intern video" traffic would somehow get DSCP best-effort
       marked. We can probably keep the whee and why of that marking
       outside of the scope of ANCP, even if it happens (orthogonal to ANCP)
       in the NAS. Correct ?

    II) To make sure that this best-effort traffic would not cause
        congestion/packet-loss of actually admission controlled video,
        the AN would need to support well enough some form of DSCP-class
        based queuing, by which some part of the bandwidth is prioritized
        for DSCP-video-class traffic, which is the class for which ANCP
        would also do admission control, eg: via grey-list.
        The best-effort-DSCP video traffic might use this bandwidth,
        but only when no DSCP-video-class traffic needs it.

        Correct ? Which of these AN side queuing behavior do you think
        should be documented by ANCP ?
    
    III) The way that ANCP would cope withsuch trafic that wouldnot be
         subject to it's admission control would as far as i  understand
         it best be to just whitelist it. So the "internet-video" with
         DSCP-best-effort would be part of the whitelist. In addition,
         if we feel that such "internet-video" traffic might have
         "unpredictable" addresses, then one might want to have matching
         against whitelist be done by default, but if the adress of
         a channel matches tthe greylist, then that greylist should
         trace precedence.

         Correct ?

b) Now, in your second mail, you indicate that the NAS should provide
   to the AN per-flow bandwidth information, such that the AN can do
   add up on it's own bandwidth of flows to make admission control decisions.
   This seems to be a diffeent approach to what i thought was expressed
   by the first mail. 

Can you calrify ??

Thanks
    Toerless

P.S.: just returning from longer vacations, so i may be more confused than
usual ;-))

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
"The strategy is what you do, not what you write" - Wesley Clark

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Wed, 16 Jan 2008 20:17:30 +0100

Hi Toerless,

The confusion probably comes from the fact that 2 discussions are mixed:

Initial question: what should the AN do when an IGMP join does not match
any white/black/grey list?  There the assumption is that such a join is
for an unknown Internet video stream, which is best effort and also
marked as best effort (using 802.1p bits is more appropriate than DSCP
since the AN is a switch).  Hence, the AN can accept this join without
doing any further CAC.

Note: since in any list you can configure a "catch-all" entry, we have a
"configurable default" but also this needs a default.

This discussion raised a second question on the need for CAC and how CAC
should be done.   There may also be a number of premium content channels
that are offered by the service provider.  The premium content channels
will not be offered as best effort, and will require CAC to be
performed. DSL lines are of limited bandwidth and CAC on such links is
useful.  Today, such CAC in performed by ANs and used by many service
providers because it is an easy and simple solution.

These premium channels may also be part of the white list, in particular
the popular channels, and channels for which the authorization
information is not changing frequently.  The white list contains the
multicast streams for which the AN can decide autonomously, and
therefore, the AN also needs the information to do this.  Therefore,
just listing the multicast streams in the white list is just not
sufficient and the AN needs the bandwidth in the white list as well.

I feel there is a need to describe this into more detail in the
framework document to make sure we understand all the same.  Also, the
explanation above also does not provide the whole story on CAC, and all
details should be in the framework.  Is this also your understanding
because then we have to work on describing all the details.

regards,
Stefaan

---

From: Tina TSOU <[email-masked]>
Date: Thu, 17 Jan 2008 17:59:53 +0900

Hi All,
There are scenarios where AN is capable of doing unicast and
multicast Admission Control for the access line. In these cases, a
subscriber request for a unicast flow (e.g. a Video on Demand session)
will trigger a resource request message towards a Policy Server; the
latter will then query the AN, that in turn will perform unicast CAC for
the access line and respond, indicating whether the unicast request is
to be honored or denied.
Current ANCP framework draft already mentions the described scenario
proposing two possible approaches:
1. Policy Server querying the AN directly (the approach doesn't require
the use of ANCP.  It is therefore beyond the scope of this document)
2. Policy Server querying the AN indirectly via the NAS.

The second approach requires a control messages exchange between NAS and
AN thus it could fit in the ANCP framework. For the purpose of
flexibility and completeness we believe it would be worth to include
this use case and the related requirements in the current ANCP framework
draft.

Please see the text proposal for the described use case and requirements
below.
Feedback and comments are welcome.

Thanks and best regards,
Tina and Roberta

Section 3.4.2
Current text:
"Another approach is the reverse: it consists of the Policy Server
      querying the AN (either directly, or indirectly via the NAS) so
      that both unicast and multicast CAC for the access line are
      performed by the AN.  In this case, a subscriber request for a
      unicast flow (e.g. a Video on Demand session) will trigger a
      resource request message towards a Policy Server; the latter will
      then query the AN, that in turn will perform unicast CAC for the
      access line and respond, indicating whether the unicast request is
      to be honored or denied.  In case the Policy Server queries the AN
      directly, the approach doesn't require the use of ANCP.  It is
      therefore beyond the scope of this document."

Adding:

"In case the Policy Server queries the AN indirectly via the NAS this
interaction can be handled as an ANCP transaction, in particular the
Policy Server queries the NAS using a protocol that is out of scope of
this document, then the NAS uses ANCP to query the AN specifying the
Access-Loop-Circuit-ID and the required Bandwidth for the requested
unicast flow. The AN on receiving the query from the NAS performs the
Admission Control check and in turn responds indicating if this unicast
VoD request needs to be accepted or denied.

Protocol Requirements
Section 4.2
The ANCP MUST allow the NAS to query the AN to request an admission
decision for a unicast flow that will contend the bandwidth with the
multicast streams for a particular Access Port.

AN Requirements
Section 4.7.6
Upon receiving a query from the NAS for a unicast flow (e.g. a Video on
Demand session) request contending the bandwidth with the multicast
streams for a particular Access Port, the AN MUST support using ANCP to
reply to the NAS indicating whether the request is to be accepted or
denied.

NAS Requirements
Section 4.8.6
Upon receiving a request for a unicast flow (e.g. a Video on Demand
session) for a specific Access Port,  from the Policy Server, the NAS
MUST support using ANCP to query the AN to receive a response indicating
whether this unicast flow is to be accepted  or denied.

----- Original Message ----- 
From: "Toerless Eckert" <[email-masked]>
To: "Stefaan DE CNODDER" <[email-masked]>
Cc: "OOGHE Sven" <[email-masked]>; <[email-masked]>
Sent: Thursday, January 17, 2008 12:18 AM
Subject: Re: [ANCP] Multicast BW Admission Control

>> >>policy
>> >>Node
>> >>streams
>> >>the

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Thu, 17 Jan 2008 13:02:16 +0100

Hi Tina,

That's indeed a good description of what we need.

see below for more comments....

> the access line and respond, indicating whether the unicast request is

If the AN is doing the CAC, it also need to have the information to do 
this CAC.  So here the current proposal is that in case of a white list, 
the NAS adds the bandwidth information to the multicast stream, such 
that upon receiving a join that matches the white list, the AN can do 
all checks including bandwidth check.  Something similar can be done for 
grey list.

Is this also how you think about it?

> 2. Policy Server querying the AN indirectly via the NAS.

Sounds good to me.  A small question: for case 2 is it "MUST be ANCP", 
or "Can be any protocol like in 1 and ANCP is not excluded"?

Thanks,
Stefaan

> ----- Original Message ----- From: "Toerless Eckert" <[email-masked]>
>>> sense
>>> make

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Thu, 17 Jan 2008 16:49:31 +0100

Hi Michael, All

thanks for you feedback and the additional caveat. It seems that 1b is the preferred way forward, so unless someone objects between now and the end of January, it's settled. A small remark about this "known caveats" section; it should be clearly stated that it is not normative, and not required to implement ANCP on either the NAS or the AN.

Regards,
Woj.

> From: Busser, M [mailto:[email-masked]] 
> Sent: 16 January 2008 08:32
> To: [email-masked]; Wojciech Dec (wdec)
> Cc: [email-masked]
> Subject: AW: [ANCP] Depreciation of TLVs ... again
> 
> All.
> 
> It it also not used by RAM or OAM at the moment (as far as I 
> know), so we shouldn't have problems with that.
> 
> Those systems will never send a subTLV 0x91. If the NAS 
> receives a subTLV 0x90, it should interpret this subTLV as DSL-Type.
> 
> If we have a AN running a later version of the draft, the NAS 
> will at least receive a subTLV 0x91 because this is 
> mandatory. It may also receive a subTLV 0x90, wich is optional. 
> In this case, the NAS should interpret 0x90 as 
> Access-Loop-Encapsulation and 0x91 as DSL-Type.
> 
> The other changes we made, concerns the length of some 
> parameters. This can be solved by the AN vendors, as long as 
> we have different implementations at the NAS side in that 
> specific detail.
> Depending on the implementation at the NAS, a AN can receive 
> the OAM-Loopback-Test-Parameter with length=8 as well as with 
> length=4 byte.
> But even if the group decide to have an ANCP version number, 
> we need an agreement, how to proceed from the actually 
> running implementations. 
> 
> Best Regards
> 
> Michael Busser
> 
> However, this is 
> avoided, but