Subject: [ANCP] Draft minutes of ANCP meeting

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 24 Mar 2010 17:55:02 -0700

Matthew, Woj, and all ANCPers,

Below are the draft minutes of the ANCP WG.
All feel free to comment/correct.
Apologies for name butchering.
Francois

========================================

ANCP WG, Wed March 24, 2010, 9:00-11:30am
Anaheim, IETF 77

* agenda review
* administrativia

* milestones need to be updated.
eg push back some of them to reflect actual progress:
	* ancp-proto
	* mib
	* mcast
Chairs will update milestones and post to list.

* Documents:
see slide. 
Note: first ANCP RFC is out (Security Threat Analysis)

=================================================

* Protocol for Access Node Control Mechanism in Broadband Networks
 Roberta. Maglione, 
http://tools.ietf.org/html/draft-ietf-ancp-protocol
see slides. describe changes & open issues.

3 open issues:

o remove mcast capabilities from ancp-protocol:
Roberta Maglione: was discussed on the list. reached agreement with Thomas to remove codepoint 03 from ancp-proto and just have value reserved. 
Birgit (represents Thomas): should not be removed 
Roberta: Thomas agreed on list to mark code as reserved
Tom Taylor: ancp-proto draft should not be required to specify all capabilities. This is to ensure extendability.
Francois: agrees that ancp-proto need not have all capabilities and that mcast capabilities should be removed from ancp-proto.
Woj: Agreement to remove 03 from ancp-proto , this will be confirmed on list

o Proposal to remove sub-TLV
Tom: there is only one complexity associated with that. It is described in ancp-mcast preso (padding issue)
Chairs: we'll deal with that during mcast preso
Woj: sub-TLVs also used in base
Tom: calling them TLVs (instead of sub-TLV) does no harm. the only issue is padding
Birgit: my understanding is there is no need to change ancp-proto
Woj:  it affects ancp-proto because it used to use sub-TLV
Tom: well, other than text, it only affects the merging of the IANA registry
Birgit: so it does not affect implementation (ie codepoints don't change)
Tom: That's right.

o Redundant extension block length
Roberta: suggest to keep the redundancy to avoid changing the spec at that late stage
Tom: I think this was brought up by Fortune
Fortune: my comment was about redundant message type
Roberta: this is a different topic. that was already clarified on the list.
Woj: we have a new protocol version in ancp-proto, so we have the opportunity to clean it up. should we?
Tom: there has been resistance to changes before, so there probably would be here too
Tom: in ancp-mcast there are other occurrences of redundancy
Woj: let's keep the cautious approach of not making change. If anyone disagrees, please comment on list

Next Step:Ready for WG Last Call?
Tom: I've noticed a few mistakes in codepoints (Hex vs decimal)
Tom: I had made an editorial proposal
Roberta: It is a major restructure, so create lots of work.
Tom: I can write a Taylor version and people can review and choose
Francois: it seems like a lot of editorial/review work just for editorial enhancements
Tom: OK I withdraw the proposal
Woj: we'll go for WG Last Call
volunteers to review: 5 or 6 (Tom, Fortune, ???...)

===========================================

Multicast Control Extensions for ANCP - Tom Taylor
http://tools.ietf.org/html/draft-ietf-ancp-mc-extensions

See slides. Describes changes

Fragmentation was added 
Woj: given that ANCP rides on TCP do you still need ANCP fragmentation?
Tom: what I am worried about is during transmit of a huge message (perhaps not so critical such as Stats reporting), all other ANCP messages would get held back
Woj: concerned that it may be somewhat underspecified
Woj: should we include in ancp-proto, as it could be applicable to other usage than just mcast?
Tom: good idea. I can propose text for that
Woj: Ok. Tom will propose text to move fragmentation into ancp-proto

Alan Kanavan: what was rationale for removing R flag?
Tom: part of the overall change that removes per-flow decision to do admission control or not
Alan: is this discussed in ancp-proto?
Tom: no discussed, in ancp-mcast
Alan: then I am fine

Roberta: Q for clarification. currently Command TLV is defined in ancp-proto, so do your change affect ancp-proto?  
Tom: ancp-proto just has the header and the TLVs are to be defined in other specs (such as ancp-mcast)

Padding issue:
Tom: this is really a ancp-proto issue. Recommendation is to do alignment as shown on slide.
Woj: this would be a clarification in ancp-proto?
Tom: Yes. I'll propose text.
who has read: 6 people

Kris Poscic: Question regarding whether a use case of interest can be supported with defined mechanisms
use case is where AN does AC and does IGMP suppression. All I want to do is report bandwidth usage to NAS (eg so NAS adjusts Qos). I saw bandwidth allocation and query. but not quite the same thing. Can this use case be supported?
Francois: can possibly be emulated with Bandwidth Delegation capability
Chris: possibly but that would not be optimal
Francois: I can agree probably agree with that. Let's have a discussion off-line.

Next Steps
Woj: close/address question from Kris. 
Could go to WG Last Call after this is closed and after ancp-proto goes to WG Last Call

===========================================

Applicability of Access Node Control Mechanism to  
PON based Broadband Networks - Nabil Bitar
http://tools.ietf.org/html/draft-bitar-wadhwa-ancp-pon-03.txt

See slides: describe changes

Woj: clarification, why did you add MAC address?
Nabil Bitar: if you change address family you'd need that. (some explanations followed that the minute taker did not get)

Alan Kanavan: ANCP between NAS and OLT all makes sense. Between OLT and ONT/ONU do you see just ANCP?
Nabil: we see both OMCI and ANCP be used there. But we only talk here about ANCP as this is the ANCP WG. We are not saying OMCI will not be used.
Birgit: will you take that work to BBF?
Nabil: planning to take that to BBF
Alan: support that work. very glad to see it happening. Wasn't the intention to fold into ancp-framework?
Nabil: we had agreed to have it as standalone
JongJin: BBF does not discuss VoD. we should look more into the differences between DSL and PON.
Nabil: we have the intention to take it to BBF. the I-D actually tries to capture the delta bw DSL & PON. Please comment if something missing there.
Alan: another difference in BBF is that they handle wholesale model. So that would have to be addressed to go to BBF. Wholesale not applicable here. What do the chairs recommend: fold wholesale into PON draft or not?
Woj: we'd like to see a proposal for Wholesale. Probably it would be a separate I-D
Nabil: so you are saying that Wholesale model applies both to DSL and PON.
Woj: yes.

===========================================

ANCP NAS MIB - M. Rohit (presented by Woj)
draft-rohit-ancp-nas-mib-00.txt

see slides. describe overview 

Francois: clarification. Does this aim at covering all of ancp-base, and not ancp-mcast
Woj: yes and yes.

Q: who has read?
noone 
Woj: usual situation for MIB, but this is a WG item

Matthew: will request on list to review and comment about making it WG draft 

===========================================

Network Anti-Attack for ANCP - B. Wu 
http://tools.ietf.org/id/draft-fan-ancp-network-anti-attack-00.txt 

See slides. provides overview.
Proposes extension to ANCP to allow distributed protection enforcement on AN instead of NAS.
eg NAS uses ANCP to tell AN to block an attacking flow.

Presenter: BBF has a reqt doc for this
Alan: it has been discussed but not quite agreed.
Alan: I have a stack of questions. First, you targeting attack on BNG or behind
Presenter: both
Alan: SPs don't care if attack is to other hosts. for the BNG, SPs already have standard protection (eg ACL)
Alan: if attack is detected, then what do you do. Block port? block MAC address? rate-limit?
Presenter: action depends on the attack. generally block MAC works well
Alan: what happens if you have enterprise network attached. Blocking MAC would block the whole enterprise. you don't want that.

Woj: let me step back. First is there interest in the use case?
Junjing: talking for BBF. There is interest in Security and in concept of using ANCP for that
Roberta: BBF accepted this use case for ANCP but inquired about whether there was ANCP protocol machinery for that
Matthew: would be useful to have liaison from BBF.
Woj: also there seems to be some interest here eg Roberta you interested?
Roberta : yes.
Woj: please update draft based on input
Alan: concepts has been presented couple of times in BBF, but it is not obvious that ANCP is the mechanism.
If NAS is not attackable (thanks to usual protection) and AN is not addressable, why do need something from ANCP? 
Woj: does L2CP/ANCP use case doc actually discuss that?
JungJing: yes, the L2CP/ANCP document discusses use of ANCP for security

10:31am. Meeting closes.

---

From: "DE CNODDER Stefaan" <[email-masked]>
Date: Thu, 25 Mar 2010 10:13:43 +0100

Hi,

Regarding to the NAS MIB, I presented 2 years ago in Dublin also a NAS
MIB (draft-decnodder-ancp-mib-nas-00.txt) which is similar as the NAS
MIB defined in draft-rohit-ancp-nas-mib-00.txt.  In Dublin, the
conclusion was that since the AN MIB was progressing very very slowly
because of lack of reviewers, the WG should not take in more MIB work,
and at that time it was also a WG item.  So why is there again the
discussion on NAS MIB?  It was already decided.

regards,
Stefaan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Francois Le Faucheur
Sent: donderdag 25 maart 2010 1:55
To: BOCCI Matthew; Dec Wojciech
Cc: [email-masked]
Subject: [ANCP] Draft minutes of ANCP meeting

* agenda review
* administrativia

* Documents:
see slide. 

3 open issues:

o remove mcast capabilities from ancp-protocol:
Roberta Maglione: was discussed on the list. reached agreement with
Thomas to remove codepoint 03 from ancp-proto and just have value
reserved. 
Birgit (represents Thomas): should not be removed 
Roberta: Thomas agreed on list to mark code as reserved
Tom Taylor: ancp-proto draft should not be required to specify all
capabilities. This is to ensure extendability.
Francois: agrees that ancp-proto need not have all capabilities and that
mcast capabilities should be removed from ancp-proto.
Woj: Agreement to remove 03 from ancp-proto , this will be confirmed on
list

o Proposal to remove sub-TLV
Tom: there is only one complexity associated with that. It is described
in ancp-mcast preso (padding issue)
Chairs: we'll deal with that during mcast preso
Woj: sub-TLVs also used in base
Tom: calling them TLVs (instead of sub-TLV) does no harm. the only issue
is padding
Birgit: my understanding is there is no need to change ancp-proto
Woj:  it affects ancp-proto because it used to use sub-TLV
Tom: well, other than text, it only affects the merging of the IANA
registry
Birgit: so it does not affect implementation (ie codepoints don't
change)
Tom: That's right.

o Redundant extension block length
Roberta: suggest to keep the redundancy to avoid changing the spec at
that late stage
Tom: I think this was brought up by Fortune
Fortune: my comment was about redundant message type
Roberta: this is a different topic. that was already clarified on the
list.
Woj: we have a new protocol version in ancp-proto, so we have the
opportunity to clean it up. should we?
Tom: there has been resistance to changes before, so there probably
would be here too
Tom: in ancp-mcast there are other occurrences of redundancy
Woj: let's keep the cautious approach of not making change. If anyone
disagrees, please comment on list

Francois: it seems like a lot of editorial/review work just for
editorial enhancements

Fragmentation was added 
Woj: given that ANCP rides on TCP do you still need ANCP fragmentation?
Tom: what I am worried about is during transmit of a huge message
(perhaps not so critical such as Stats reporting), all other ANCP
messages would get held back
Woj: concerned that it may be somewhat underspecified
Woj: should we include in ancp-proto, as it could be applicable to other
usage than just mcast?
Tom: good idea. I can propose text for that
Woj: Ok. Tom will propose text to move fragmentation into ancp-proto

Alan Kanavan: what was rationale for removing R flag?
Tom: part of the overall change that removes per-flow decision to do
admission control or not
Alan: is this discussed in ancp-proto?
Tom: no discussed, in ancp-mcast
Alan: then I am fine

Roberta: Q for clarification. currently Command TLV is defined in
ancp-proto, so do your change affect ancp-proto?  
Tom: ancp-proto just has the header and the TLVs are to be defined in
other specs (such as ancp-mcast)

Padding issue:
Tom: this is really a ancp-proto issue. Recommendation is to do
alignment as shown on slide.
Woj: this would be a clarification in ancp-proto?
Tom: Yes. I'll propose text.
who has read: 6 people

Kris Poscic: Question regarding whether a use case of interest can be
supported with defined mechanisms
use case is where AN does AC and does IGMP suppression. All I want to do
is report bandwidth usage to NAS (eg so NAS adjusts Qos). I saw
bandwidth allocation and query. but not quite the same thing. Can this
use case be supported?
Francois: can possibly be emulated with Bandwidth Delegation capability
Chris: possibly but that would not be optimal
Francois: I can agree probably agree with that. Let's have a discussion
off-line.

Next Steps
Woj: close/address question from Kris. 
Could go to WG Last Call after this is closed and after ancp-proto goes
to WG Last Call

Woj: clarification, why did you add MAC address?
Nabil Bitar: if you change address family you'd need that. (some
explanations followed that the minute taker did not get)

Alan Kanavan: ANCP between NAS and OLT all makes sense. Between OLT and
ONT/ONU do you see just ANCP?
Nabil: we see both OMCI and ANCP be used there. But we only talk here
about ANCP as this is the ANCP WG. We are not saying OMCI will not be
used.
Birgit: will you take that work to BBF?
Nabil: planning to take that to BBF
Alan: support that work. very glad to see it happening. Wasn't the
intention to fold into ancp-framework?
Nabil: we had agreed to have it as standalone
JongJin: BBF does not discuss VoD. we should look more into the
differences between DSL and PON.
Nabil: we have the intention to take it to BBF. the I-D actually tries
to capture the delta bw DSL & PON. Please comment if something missing
there.
Alan: another difference in BBF is that they handle wholesale model. So
that would have to be addressed to go to BBF. Wholesale not applicable
here. What do the chairs recommend: fold wholesale into PON draft or
not?
Woj: we'd like to see a proposal for Wholesale. Probably it would be a
separate I-D
Nabil: so you are saying that Wholesale model applies both to DSL and
PON.
Woj: yes.

Francois: clarification. Does this aim at covering all of ancp-base, and
not ancp-mcast
Woj: yes and yes.

Q: who has read?
noone 

Matthew: will request on list to review and comment about making it WG
draft 

See slides. provides overview.
Proposes extension to ANCP to allow distributed protection enforcement
on AN instead of NAS.
eg NAS uses ANCP to tell AN to block an attacking flow.

Presenter: BBF has a reqt doc for this
Alan: it has been discussed but not quite agreed.
Alan: I have a stack of questions. First, you targeting attack on BNG or
behind
Presenter: both
Alan: SPs don't care if attack is to other hosts. for the BNG, SPs
already have standard protection (eg ACL)
Alan: if attack is detected, then what do you do. Block port? block MAC
address? rate-limit?
Presenter: action depends on the attack. generally block MAC works well
Alan: what happens if you have enterprise network attached. Blocking MAC
would block the whole enterprise. you don't want that.

Woj: let me step back. First is there interest in the use case?
Junjing: talking for BBF. There is interest in Security and in concept
of using ANCP for that
Roberta: BBF accepted this use case for ANCP but inquired about whether
there was ANCP protocol machinery for that
Matthew: would be useful to have liaison from BBF.
Woj: also there seems to be some interest here eg Roberta you
interested?
Roberta : yes.
Woj: please update draft based on input
Alan: concepts has been presented couple of times in BBF, but it is not
obvious that ANCP is the mechanism.
If NAS is not attackable (thanks to usual protection) and AN is not
addressable, why do need something from ANCP? 
Woj: does L2CP/ANCP use case doc actually discuss that?
JungJing: yes, the L2CP/ANCP document discusses use of ANCP for security

10:31am. Meeting closes.
_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 25 Mar 2010 18:59:02 -0700

Finishing the MIBs is part of the WG charter.
We also have contributors who appear to have interest in progressing it, and
given that there appears not be technical issues, there is no reason for NOT
adopting the draft as a WG I-D.
You're more than welcome to contribute to the draft.

-Woj.

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 30 Mar 2010 17:03:06 +0200

Folks,

Following up on this item.

> Francois: I can agree probably agree with that. Let's have a discussion off-line.

We had a chat after the meeting and I also discussed this with Tom and then with Woj. There seems to be agreement that this is a valid use case worth addressing. We discussed an approach along the lines of:
	* define a new capability for "admitted bandwidth reporting" (actual name is TBD)
	* if the capability is negotiated, the AN MUST report to the NAS the new value of the bandwidth currently allocated/admitted by the AN on a given port whenever that value changes (eg the AN just admitted another multicast channel in the White List, or the user just jumped from and SD channel to a HD channel,..).
	* the AN is allowed to make some judgment calls about when to report a changed admitted bandwidth. For example, when the AN receives the leave, the AN may want to wait a little before reporting the changed admitted bandwidth in case a join comes in (say because user is simply changing channel).
	* on receipt of a new admitted bandwidth value, the NAS MAY adjust its QoS mechanisms accordingly (note that, when doing so, the NAS needs to take into account the rest of the video traffic that is not admitted by the AN such as unicast VoD traffic or NAS Initiated Multicast traffic.
	* the call flow to report a new admitted bandwidth value will only involve a message in the direction AN-->NAS. No response is needed from NAS (except in case of errored message as per usual ANCP procedures).
	* we'll look into whether the AN-->NAS message used for admitted bandwidth reporting should be a new message type or piggy-backed using an existing message (eg PortUp, Generic Response,..)
	* one question that needs more thoughts is combination of this new capability with various other multicast capabilities (eg what should be done when we have both this new capability and Grey List, since the NAS is already aware of all admitted multicast grey groups). I don't think any of that should be a show stopper, but it has to be carefully walked through.

High level feedback is welcome on this before we start working out details.

Oh, last thing, does anyone know whether this use case is already discussed in the Framework document?

Thanks

Francois

---

From: "POSCIC Kristian" <[email-masked]>
Date: Tue, 30 Mar 2010 18:45:35 -0500

Thanks Francois. 
This sums it up well. 
Some additional comments inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Francois Le Faucheur
Sent: Tuesday, March 30, 2010 8:03 AM
To: [email-masked]
Subject: [ANCP] "Admitted Bandwidth Reporting" multicast use case

Folks,

> use case is where AN does AC and does IGMP suppression. All I want to
do is report bandwidth usage to NAS (eg so NAS adjusts Qos). I saw
bandwidth allocation and query. but not quite the same thing. Can this
use case be supported?
> Francois: I can agree probably agree with that. Let's have a
discussion off-line.

We had a chat after the meeting and I also discussed this with Tom and
then with Woj. There seems to be agreement that this is a valid use case
worth addressing. We discussed an approach along the lines of:
	* define a new capability for "admitted bandwidth reporting"
(actual name is TBD)
	* if the capability is negotiated, the AN MUST report to the NAS
the new value of the bandwidth currently allocated/admitted by the AN on
a given port whenever that value changes (eg the AN just admitted
another multicast channel in the White List, or the user just jumped
from and SD channel to a HD channel,..).
	* the AN is allowed to make some judgment calls about when to
report a changed admitted bandwidth. For example, when the AN receives
the leave, the AN may want to wait a little before reporting the changed
admitted bandwidth in case a join comes in (say because user is simply
changing channel).
	* on receipt of a new admitted bandwidth value, the NAS MAY
adjust its QoS mechanisms accordingly (note that, when doing so, the NAS
needs to take into account the rest of the video traffic that is not
admitted by the AN such as unicast VoD traffic or NAS Initiated
Multicast traffic.

[Kris]  Little more details for a possible use case: This feature will
be primarily used when the multicast is sent from the NAS towards the AN
over a common multicast VLAN. Since the subscriber QoS context in the
NAS actually does not see this mcast traffic, (mcast traffic is sent
over a separate common VLAN), QoS b/w adjustment needs to be made for
the subscriber. Most likely, every other traffic that is flowing
directly over subscribers queues in the NAS will be automatically
included in the subscriber QoS. This would include any unicast video
streams that are directly flowing over the subscriber queues.
   
	* the call flow to report a new admitted bandwidth value will
only involve a message in the direction AN-->NAS. No response is needed
from NAS (except in case of errored message as per usual ANCP
procedures).
	* we'll look into whether the AN-->NAS message used for admitted
bandwidth reporting should be a new message type or piggy-backed using
an existing message (eg PortUp, Generic Response,..)

[Kris] 
Do we report the diff in b/w usage or the total b/w used value per
access port? I think that the 'total usage' should be certainly a
priority. Possibly you can include a flag that would indicate that a
diff in b/w usage is reported. 
 
	* one question that needs more thoughts is combination of this
new capability with various other multicast capabilities (eg what should
be done when we have both this new capability and Grey List, since the
NAS is already aware of all admitted multicast grey groups). I don't
think any of that should be a show stopper, but it has to be carefully
walked through.

[Kris] This is my (maybe skewed :)) view on this: QoS B/W adjustment in
the NAS can be done based on IGMPs received from the AN or based on this
new model (proposed here) via ANCP. The latter would be normally the
case in the absence of IGMP messages reaching the NAS (there are valid
reasons to do this). Which option to chose is up to the operator and it
is controlled in the NAS. 
The AN asking for the NAS for the resource admission via the grey lists
should be orthogonal to b/w adjustment. 
Thanks again Francois.     

High level feedback is welcome on this before we start working out
details.

Oh, last thing, does anyone know whether this use case is already
discussed in the Framework document?

Thanks

Francois