Subject: Re: [ANCP] capability 03 and 05

From: "DE CNODDER Stefaan" <[email-masked]>
Date: Tue, 13 Apr 2010 15:54:01 +0200

Hi,

What was the conclusion of this topic?  I understood from the meeting minutes that capability 03 will be removed from draft-proto since it is not defined and not used in any other document, but will the other capabilities from the multicast draft be put in the base spec?

When I know what will be done, I can update the MIB because it depends on the capabilities defined in the base spec.

regards,
Stefaan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: maandag 22 maart 2010 10:24
To: [email-masked]
Cc: [email-masked]; [email-masked]; DE CNODDER Stefaan; [email-masked]
Subject: AW: [ANCP] capability 03 and 05

Tom,

I agree in  marking the codepoint in base document as reserved for multicast , while the Multicast Extensions document assigns to the right capability.  

Regards
Thomas

-----Ursprüngliche Nachricht-----
Von: Tom Taylor [mailto:[email-masked]] 
Gesendet: Samstag, 20. März 2010 03:52
An: Haag, Thomas
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [ANCP] capability 03 and 05

Thomas, doing that would mean we could never again extend ANCP. I expect your 
real concern is to protect that codepoint. For that, the solution is simple: the 
base document marks the codepoint as Reserved, and the Multicast Extensions 
document assigns it to the right capability from your point of view.

Tom Taylor

[email-masked] wrote:
> Hi Roberta,
> 
> I agree that multicast at all should be covered by a seperate document. There is no doubt about.
> 
> But my point was that codings of a specific field belonging to capability negotiation in the base protocol draft which refer to a dedicated ues case described in an additional document must be named in the base protocol draft and cannot be removed from that. Without capability negotiation of basic protocol no workable multicast use case!   
> 
> Regards
> 
> Thomas
> 
> -----Ursprüngliche Nachricht-----
> Von: Maglione Roberta [mailto:[email-masked]] 
> Gesendet: Donnerstag, 18. März 2010 09:16
> An: Haag, Thomas; [email-masked]; [email-masked]
> Cc: [email-masked]
> Betreff: RE: [ANCP] capability 03 and 05
> 
> Hi Thomas,
>      If I remember correctly, the working group agreed almost one year ago to keep multicast extensions in a separate draft: the multicast draft is now a WG item part of the ancp charter.
>  As Stefaan and Francois pointed out, the multicast draft already contains a dedicated section for multicast capabilities, thus in opinion  the multicast related capabilities should be removed from the ancp-protocol draft.
> 
> Best Regards,
> Roberta
> 
> ________________________________________
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, March 18, 2010 8:23 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [ANCP] capability 03 and 05
> 
> All,
> 
> from my understanding capability negotiation is a basic protocol element coming along with adjacency which must be fully described in protocol draft.
> 
> So from my understanding the code for multicast must be kept in protocol draft. I don't recommend removing certain capability codes from this basic draft becasue I think from the logical order all drafts must refer to protocol draft as basic draft and not defining basic elements/codes seperately.
> 
> Regards
> Thomas
> 
> 
> ________________________________________
> Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Francois Le Faucheur
> Gesendet: Mittwoch, 17. März 2010 18:24
> An: DE CNODDER Stefaan
> Cc: [email-masked]
> Betreff: Re: [ANCP] capability 03 and 05
> Hi Stefaan,
> Yes, I think the multicast related capabilities need to be removed from ancp-protocol. They are covered in ancp-mc.
> 
> Do ancp-protocol co-authors agre?
> 
> On 17 Mar 2010, at 09:33, DE CNODDER Stefaan wrote:
> 
> 
> 
> Hi,
> In the protocol draft I read:
>    3.  Capability Type : Transactional-Multicast = 0x03 (controller i.e.
>        NAS terminates IGMP messages from subscribers, and via l2 control
>        protocol, signals state to the access-nodes (e.g.  DSLAMs) to
>        enable layer2 replication of multicast streams.  In ATM access
>        network this implies that NAS instructs the access-node to setup
>        a P2MP cross-connect.  The details of this will be covered in a
>        separate ID.
> Is this the same as capability 0x05 defined in draft-ietf-ancp-mc-extensions-02.txt?  It looks to be better to remove capability 0x03 from the base spec.
> regards,
> Stefaan
> 
> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ancp
> 
> 
> 
> 
> 
> Francois Le Faucheur
> Distinguished Engineer
> Corporate Development
> [email-masked]
> Phone: +33 49 723 2619
> Mobile: +33 6 19 98 50 90
> 
> Cisco Systems France
> Greenside
> 400 Ave de Roumanille
> 06410 Sophia Antipolis
> France
> Cisco.com
> 
> 
> 
>  Think before you print.
> 
> This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
> 
> Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.
> 
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
> 
> 
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.
> 
> This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
> 
> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ancp

---

From: Tom Taylor <[email-masked]>
Date: Tue, 13 Apr 2010 10:36:24 -0400

The conclusion is that the IANA section of the base document will indicate that 
capability codepoint 0x0003 is Reserved. No other changes will be made to the 
set of capabilities currently defined in the base document. The multicast 
extensions document will be updated to ensure that NAS-initiated replication is 
assigned capability value 0x0003 rather than 0x0005. We have a couple of choices 
for the remaining multicast capabilities. Because we are introducing a new 
bandwidth reporting capability (recently discussed) we could give it capability 
codepoint 0x0005 and leave the others unchanged. The second choice is to not 
assign codepoint 0x0005, leaving a hole in the sequence. The new capability 
would use codepoint 0x0009.

While I was looking at the base document to check out whether capability 
codepoints were a scarce resource, I discovered an issue, at least in my mind. 
That is, that capabilities are indicated by the presence of "capability TLVs" in 
the adjacency message. The problem is that the capability values are equivalent 
to TLV types, but are not included in the registered set of TLV types. I agree 
with that treatment, in fact, but believe that the term "capability TLV" is 
going to cause confusion. I strongly suggest that the phrase be changed instead 
to "capability field".

I also note that the multicast extensions document does not define the 
capability data for the capabilities it defines. Probably there isn't any, but 
the contents of the capability fields for multicast-related capabilities do need 
to be specified. A to-do for the editors.

DE CNODDER Stefaan wrote:
> Hi,
> 
> What was the conclusion of this topic?  I understood from the meeting minutes
> that capability 03 will be removed from draft-proto since it is not defined
> and not used in any other document, but will the other capabilities from the
> multicast draft be put in the base spec?
> 
> regards, Stefaan
...