Subject: [ANCP] Agenda items for IETF75 ANCP WG meeting

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 7 Jul 2009 12:04:46 +0200

Hi All,

We're taking requests for slots in the agenda for our next ANCP WG
meeting in Stockholm. Please respond with any requests.

Thanks,
Matthew & Woj

---

From: Tom Taylor <[email-masked]>
Date: Tue, 07 Jul 2009 11:53:18 -0400

Assuming Woj approves it, it should be draft-ietf...

Francois Le Faucheur IMAP wrote:
> Hi Woj,
> 
> Can you plan a slot for "Multicast Control Extensions for ANCP"?
>  (not sure whether that will be draft-ietf-ancp-mc-extensions-00 or 
> draft-lefaucheur-ancp-mc-extensions-02).
> 
> Francois
> 
> On 7 Jul 2009, at 06:04, Wojciech Dec (wdec) wrote:
> 
>> Hi All,
>>
>>
>> _______________________________________________
>> ANCP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ancp
> 
>

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 7 Jul 2009 11:46:08 -0400

Hi Woj,

Francois

---

From: <[email-masked]>
Date: Fri, 17 Jul 2009 17:26:06 +0200

Hi all,
 
allthough discussed in the past the issue of coding a protocol version
field for ancp seems to be unavoidable. 
Earlier discussions ended up with the assumption that one final protocol
draft will exist covering the whole ancp story. 
 
This assumption is not longer valid because of four reasons:

1. Today four use cases have been identified,  three are described in
detail in the protocol specification (Topology discovery, OAM,
Multicast). 
    Use Case line configuration is described briefly but not finally
with all paramters and corresponidng TLVs. The latter use case is most
flexible and not all-embraced described because the expected 
    paramterset is not fixed today
 
2. Broadband Forum started in march 2009 a new working text dealing with
new requirements, new use cases. ANCP should be prepared for tackeling
the issue that the protocol spec will have 
    continous requirements tackling in future different versions.
Considering this today makes ancp future proof.
 
3. Allthough framework of ancp describes the usage for ancp for DSL
access, latest activities show that ancp can also be used for other
technologies like PON. 
    Therefore it is expected that dependend on adressed technology ancp
has to be open for future use - an important requirment for versioning.
 
4. Existing pre versions showing field proof implemtation of ancp have
to be recognised as well and to be handled in the same manner. Therefore
an indication is neccessary to identifiy protocol versions.

Facing all listed issues an operator needs to identify ancp versions
because nobody in the world will upgrade 1 BRAS and up 5000 access nodes
simoultanously.
This has to be recognised making ancp carrier grade.
 
Therefore I propose ancp working group to address this issue in the
agenda for the upcoming meeting in stockholm, to discuss it and find a
solution to handle the facing challenges which helps industry and
operators.
 
Ad hoc I can think of two options solving this issue:
 
Option 1: use the sub version field for ANCP - Versioning (because it is
derived from GSMP but not needed any more for ANCP purpose)
 
Option 2: define a new field or TLV for Version purpose

Best regards
 
Thomas Haag

  _____  

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
Wojciech Dec (wdec)
Gesendet: Dienstag, 7. Juli 2009 12:05
An: [email-masked]
Betreff: [ANCP] Agenda items for IETF75 ANCP WG meeting

Hi All, 

Thanks, 
Matthew & Woj

---

From: Sidd Aanand <[email-masked]>
Date: Fri, 17 Jul 2009 11:54:00 -0400

Thomas,

I am not sure I understand the problem here. There is already a version,
sub-version field defined in the current draft that get set to 3 and 1
respectively. Are we trying to define a method so that different
version/sub-version implementations can handshake prior to establishing
an adjacency or is there some other problem.
 
Thanks,
Sidd

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, July 17, 2009 11:26 AM
To: [email-masked]
Subject: Re: [ANCP] Agenda items for IETF75 ANCP WG meeting

Hi all,

 

 

 

Best regards
 
Thomas Haag

________________________________

Hi All, 

Thanks, 
Matthew & Woj

---

From: Tom Taylor <[email-masked]>
Date: Fri, 17 Jul 2009 12:02:03 -0400

Don't the capabilities satisfy this requirement?

[email-masked] wrote:
> detail in the protocol specification (Topology discovery, OAM, Multicast).
> solution to handle the facing challenges which helps industry and operators.
>  
> ------------------------------------------------------------------------
> *Von:* [email-masked] [mailto:[email-masked]] *Im Auftrag 
> von *Wojciech Dec (wdec)
> *Gesendet:* Dienstag, 7. Juli 2009 12:05
> *An:* [email-masked]
> *Betreff:* [ANCP] Agenda items for IETF75 ANCP WG meeting
> 
> Hi All,
> 
> 
> ------------------------------------------------------------------------
>

---

From: <[email-masked]>
Date: Mon, 20 Jul 2009 09:07:06 +0200

Tom,

no, the capabilities adresses the supported use cases only. As stated not all use cases are coded finally.

Requested versioning would provide a function distinguishing different codes.

Regards
Thomas

---

From: Hongyu Li <[email-masked]>
Date: Thu, 23 Jul 2009 09:17:55 +0800

Since this is a problem we have to solve, it should be solved the earlier the better. Meeting in Stockholm is a good chance.

Cheers,
Hongyu

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, July 17, 2009 11:26 PM
To: [email-masked]
Subject: Re: [ANCP] Agenda items for IETF75 ANCP WG meeting

Hi all,
 
allthough discussed in the past the issue of coding a protocol version field for ancp seems to be unavoidable. 
Earlier discussions ended up with the assumption that one final protocol draft will exist covering the whole ancp story. 

1. Today four use cases have been identified,  three are described in detail in the protocol specification (Topology discovery, OAM,
Multicast). 
    Use Case line configuration is described briefly but not finally with all paramters and corresponidng TLVs. The latter use case
is most flexible and not all-embraced described because the expected 
    paramterset is not fixed today
 
2. Broadband Forum started in march 2009 a new working text dealing with new requirements, new use cases. ANCP should be prepared
for tackeling the issue that the protocol spec will have 
    continous requirements tackling in future different versions. Considering this today makes ancp future proof.
 
3. Allthough framework of ancp describes the usage for ancp for DSL access, latest activities show that ancp can also be used for
other technologies like PON. 
    Therefore it is expected that dependend on adressed technology ancp has to be open for future use - an important requirment for
versioning.
 
4. Existing pre versions showing field proof implemtation of ancp have to be recognised as well and to be handled in the same
manner. Therefore an indication is neccessary to identifiy protocol versions.

Facing all listed issues an operator needs to identify ancp versions because nobody in the world will upgrade 1 BRAS and up 5000
access nodes simoultanously.
This has to be recognised making ancp carrier grade.
 
Therefore I propose ancp working group to address this issue in the agenda for the upcoming meeting in stockholm, to discuss it and
find a solution to handle the facing challenges which helps industry and operators.

Option 1: use the sub version field for ANCP - Versioning (because it is derived from GSMP but not needed any more for ANCP purpose)

Best regards
 
Thomas Haag

  _____  

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Wojciech Dec (wdec)
Gesendet: Dienstag, 7. Juli 2009 12:05
An: [email-masked]
Betreff: [ANCP] Agenda items for IETF75 ANCP WG meeting

Hi All, 

We're taking requests for slots in the agenda for our next ANCP WG meeting in Stockholm. Please respond with any requests.

Thanks, 
Matthew & Woj