From flefauch@cisco.com Mon Jun 8 03:39:09 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 455DA3A68CD for ; Mon, 8 Jun 2009 03:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoXSC3CFEEsp for ; Mon, 8 Jun 2009 03:39:08 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 02A9E3A685E for ; Mon, 8 Jun 2009 03:39:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,324,1241395200"; d="scan'208,217";a="42272984" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Jun 2009 10:39:12 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n58AdCOH019264; Mon, 8 Jun 2009 12:39:12 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n58AdC2Q006529; Mon, 8 Jun 2009 10:39:12 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jun 2009 12:39:12 +0200 Received: from [217.167.117.21] ([10.61.102.188]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jun 2009 12:39:11 +0200 Message-Id: <671A5BF3-6386-4741-84C2-5B3051D77DAA@cisco.com> From: Francois Le Faucheur IMAP To: BOCCI Matthew , Dec Wojciech In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-4--137621930 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 8 Jun 2009 12:39:10 +0200 References: <0458D2EE0C36744BABB36BE37805C29A039300AF@FRVELSMBS11.ad2.ad.alcatel.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 08 Jun 2009 10:39:11.0690 (UTC) FILETIME=[5C4F3AA0:01C9E825] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3623; t=1244457552; x=1245321552; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[ANCP]=20Splitting=20multicast=20from=2 0protocol=20doc |Sender:=20; bh=V5dslDCb6ZOoI+yKOV1W+JAI0aFp1lo0xx1isD2P5/s=; b=oC8JKoIbd93FRp1mGfdH0qt0Dw3k3stgQSqX7ce3JpAQa4vrGaXV5CPt62 l5xiI3+o0xbto4C6bvc00P2cB2WJbAGJcGdiYp9unTWS8cB1/oX+dk6DWAZN h/6qDFtE7z; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ancp@ietf.org Subject: Re: [ANCP] Splitting multicast from protocol doc X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 10:39:09 -0000 --Apple-Mail-4--137621930 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Matthew, Woj, We had a few responses to this proposal. What is the final decision? Thanks Francois On 31 Mar 2009, at 22:21, Francois Le Faucheur IMAP wrote: > support. > Francois > > On 31 Mar 2009, at 17:46, BOCCI Matthew wrote: > >> There was a proposal at the last IETF to take the multicast text >> from draft-ietf-ancp-protocol-05 and merge it with draft-lefaucheur- >> ancp-mc-extensions-01. >> >> We would thus have two protocol drafts: >> >> draft-ietf-ancp-protocol : Containing the solutions for the >> Topology discovery, line configuration and OAM use cases >> Multicast extensions draft: Containing the transactional multicast >> solution and all of the content of draft-lefaucheur >> >> This would allow us to move forward with WG LC on the basic use >> case solutions, and also keep all of the multicast extensions in a >> single draft. >> >> Please can you indicate to the list whether you support this >> proposal. >> >> Regards >> >> Matthew >> >> >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www.ietf.org/mailman/listinfo/ancp > --Apple-Mail-4--137621930 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Matthew, = Woj,

We had a few responses to this proposal. What is = the final = decision?

Thanks

Francoi= s

On 31 Mar 2009, at 22:21, Francois Le Faucheur = IMAP wrote:

=

There was a proposal at the last IETF to take the = multicast text from draft-ietf-ancp-protocol-05 and merge it with = draft-lefaucheur-ancp-mc-extensions-01.

We would thus have two protocol drafts: =

draft-ietf-ancp-protocol : = Containing the solutions for the Topology discovery, line configuration = and OAM use cases
Multicast = extensions draft: Containing the transactional multicast solution and = all of the content of draft-lefaucheur

This would allow us to move forward with WG LC on the = basic use case solutions, and also keep all of the multicast extensions = in a single draft.

Please = can you indicate to the list whether you support this proposal. =

Regards

Matthew


= _______________________________________________
ANCP mailing = list
ANCP@ietf.org
https://www.ietf.org/m= ailman/listinfo/ancp


= --Apple-Mail-4--137621930-- From tena@huawei.com Mon Jun 8 03:59:06 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D65C33A6AB4 for ; Mon, 8 Jun 2009 03:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d57eRCLBgQAe for ; Mon, 8 Jun 2009 03:59:05 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 7E34B3A672F for ; Mon, 8 Jun 2009 03:59:05 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKX003IA2ICCR@szxga03-in.huawei.com> for ancp@ietf.org; Mon, 08 Jun 2009 18:59:00 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKX002AU2IBUH@szxga03-in.huawei.com> for ancp@ietf.org; Mon, 08 Jun 2009 18:59:00 +0800 (CST) Received: from [192.168.1.3] (122.138.61.58.broad.sz.gd.dynamic.163data.com.cn [58.61.138.122]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKX00AO22IA2P@szxml01-in.huawei.com>; Mon, 08 Jun 2009 18:58:59 +0800 (CST) Date: Mon, 08 Jun 2009 18:58:58 +0800 From: Tina TSOU In-reply-to: <671A5BF3-6386-4741-84C2-5B3051D77DAA@cisco.com> To: Francois Le Faucheur IMAP Message-id: <4D162095-91D8-44B3-BE20-C6245316B266@huawei.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: multipart/alternative; boundary="Boundary_(ID_vQOhUE6VhQP1vVQBjuz7ZQ)" References: <0458D2EE0C36744BABB36BE37805C29A039300AF@FRVELSMBS11.ad2.ad.alcatel.com> <671A5BF3-6386-4741-84C2-5B3051D77DAA@cisco.com> Cc: ancp@ietf.org Subject: Re: [ANCP] Splitting multicast from protocol doc X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 10:59:06 -0000 --Boundary_(ID_vQOhUE6VhQP1vVQBjuz7ZQ) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT Hi, I'm fine with either approach, as long as both of them are in the standard track. B. R. Tina http://tinatsou.weebly.com/contact.html On Jun 8, 2009, at 6:39 PM, Francois Le Faucheur IMAP wrote: > Matthew, Woj, > > We had a few responses to this proposal. What is the final decision? > > Thanks > > Francois > > On 31 Mar 2009, at 22:21, Francois Le Faucheur IMAP wrote: > >> support. >> Francois >> >> On 31 Mar 2009, at 17:46, BOCCI Matthew wrote: >> >>> There was a proposal at the last IETF to take the multicast text >>> from draft-ietf-ancp-protocol-05 and merge it with draft- >>> lefaucheur-ancp-mc-extensions-01. >>> >>> We would thus have two protocol drafts: >>> >>> draft-ietf-ancp-protocol : Containing the solutions for the >>> Topology discovery, line configuration and OAM use cases >>> Multicast extensions draft: Containing the transactional multicast >>> solution and all of the content of draft-lefaucheur >>> >>> This would allow us to move forward with WG LC on the basic use >>> case solutions, and also keep all of the multicast extensions in a >>> single draft. >>> >>> Please can you indicate to the list whether you support this >>> proposal. >>> >>> Regards >>> >>> Matthew >>> >>> >>> _______________________________________________ >>> ANCP mailing list >>> ANCP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ancp >> > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp --Boundary_(ID_vQOhUE6VhQP1vVQBjuz7ZQ) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT
Hi,
I'm fine with either approach, as long as both of them are in the standard track.
On Jun 8, 2009, at 6:39 PM, Francois Le Faucheur IMAP wrote:

Matthew, Woj,

We had a few responses to this proposal. What is the final decision?

Thanks

Francois

On 31 Mar 2009, at 22:21, Francois Le Faucheur IMAP wrote:

support.
Francois

On 31 Mar 2009, at 17:46, BOCCI Matthew wrote:

There was a proposal at the last IETF to take the multicast text from draft-ietf-ancp-protocol-05 and merge it with draft-lefaucheur-ancp-mc-extensions-01.

We would thus have two protocol drafts:

draft-ietf-ancp-protocol : Containing the solutions for the Topology discovery, line configuration and OAM use cases
Multicast extensions draft: Containing the transactional multicast solution and all of the content of draft-lefaucheur

This would allow us to move forward w ith WG L olutions, and also keep all of the multicast extensions in a single draft.

Please can you indicate to the list whether you support this proposal.

Regards

Matthew


_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www.ietf.org/mailman/listinfo/ancp


_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www.ietf.org/mailman/listinfo/ancp

--Boundary_(ID_vQOhUE6VhQP1vVQBjuz7ZQ)-- From wdec@cisco.com Mon Jun 8 04:19:12 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 955773A6E05 for ; Mon, 8 Jun 2009 04:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTOK6VuZlsIG for ; Mon, 8 Jun 2009 04:19:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C6DB03A6A75 for ; Mon, 8 Jun 2009 04:19:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,324,1241395200"; d="scan'208,217";a="42278170" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Jun 2009 11:19:14 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n58BJEAB020313; Mon, 8 Jun 2009 13:19:14 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n58BJEED020381; Mon, 8 Jun 2009 11:19:14 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jun 2009 13:19:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9E82A.F47A61C9" Date: Mon, 8 Jun 2009 13:19:09 +0200 Message-ID: In-Reply-To: <671A5BF3-6386-4741-84C2-5B3051D77DAA@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Splitting multicast from protocol doc Thread-Index: AcnoJVxyUXMHZkalQ06aQ8KRpNNWwgAAwNeA References: <0458D2EE0C36744BABB36BE37805C29A039300AF@FRVELSMBS11.ad2.ad.alcatel.com> <671A5BF3-6386-4741-84C2-5B3051D77DAA@cisco.com> From: "Wojciech Dec (wdec)" To: "Francois Le Faucheur (flefauch)" , "BOCCI Matthew" , "Maglione Roberta" X-OriginalArrivalTime: 08 Jun 2009 11:19:14.0826 (UTC) FILETIME=[F4B0AEA0:01C9E82A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7776; t=1244459954; x=1245323954; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20Splitting=20multicast=20from=2 0protocol=20doc |Sender:=20; bh=sxWF/LYiUFq6Bty601S9FGvwdrz5bU0kA9Lg/GpMrGs=; b=QeVYo9/4WjpfYHrmx0wDc3+H6Bnz/UNmBYtYIf5o7sYfYDuaKjT0vFjyaN fs8tsFgsSPKX+Ka60KqQM3Uf6AP6Lpc+qJ6n3Z1aR+5webZK/rnwED04XP8Q GiIzg70PM7; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ancp@ietf.org Subject: Re: [ANCP] Splitting multicast from protocol doc X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 11:19:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9E82A.F47A61C9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois, =20 let's go with the this approach. Some delicate surgery is needed on the ancp-protocol draft to move the mcast specific parts to the new ID, but leave the base protocol parts that have been defined (or re-defined) as part of the mcast work in the base protocol spec. A rough line to draw would be: - ANCP base header definitions, extensions -> ancp-protocol - Mcast capability negotiation, messages, message flows, error codes -> mcast ID There are some provisioning aspects of the mcast use-cases (eg the lists) that likely could apply to the wider provisioning use-case, so this could go either way. =20 It would seem like having the editors of both docs discuss the what goes where would be a good next step. =20 Regards, Woj. ________________________________ From: Francois Le Faucheur (flefauch)=20 Sent: 08 June 2009 12:39 To: BOCCI Matthew; Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: Re: [ANCP] Splitting multicast from protocol doc =09 =09 Matthew, Woj,=20 We had a few responses to this proposal. What is the final decision? Thanks Francois On 31 Mar 2009, at 22:21, Francois Le Faucheur IMAP wrote: support.=20 Francois On 31 Mar 2009, at 17:46, BOCCI Matthew wrote: There was a proposal at the last IETF to take the multicast text from draft-ietf-ancp-protocol-05 and merge it with draft-lefaucheur-ancp-mc-extensions-01. We would thus have two protocol drafts:=20 draft-ietf-ancp-protocol : Containing the solutions for the Topology discovery, line configuration and OAM use cases=20 Multicast extensions draft: Containing the transactional multicast solution and all of the content of draft-lefaucheur=20 This would allow us to move forward with WG LC on the basic use case solutions, and also keep all of the multicast extensions in a single draft. Please can you indicate to the list whether you support this proposal.=20 Regards=20 Matthew=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp =09 ------_=_NextPart_001_01C9E82A.F47A61C9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Francois,
 
let's go with the this approach. Some delicate surgery is = needed on the=20 ancp-protocol draft to move the mcast specific parts to the new ID, but = leave=20 the base protocol parts that have been defined (or re-defined) as = part of=20 the mcast work in the base protocol spec. A rough line to draw would=20 be:
-=20 ANCP base header definitions, extensions ->=20 ancp-protocol
-=20 Mcast capability negotiation, messages, message flows, error codes = ->=20 mcast ID
There are some provisioning aspects of the mcast use-cases (eg = the lists)=20 that likely could apply to the wider provisioning use-case, so this = could go=20 either way.
 
It would seem like having the editors of both docs = discuss the what=20 goes where would be a good next step.
 
Regards,
Woj.

From: Francois Le Faucheur = (flefauch)=20
Sent: 08 June 2009 12:39
To: BOCCI Matthew; = Wojciech Dec=20 (wdec)
Cc: ancp@ietf.org
Subject: Re: [ANCP] = Splitting=20 multicast from protocol doc

Matthew, Woj,

We had a few responses to this proposal. What is the final=20 decision?

Thanks

Francois

On 31 Mar 2009, at 22:21, Francois Le Faucheur IMAP = wrote:
support.
Francois

On 31 Mar 2009, at 17:46, BOCCI Matthew wrote:

There was a proposal at the last = IETF to take=20 the multicast text from draft-ietf-ancp-protocol-05 and merge it = with=20 draft-lefaucheur-ancp-mc-extensions-01.

We would thus have two protocol = drafts:=20

draft-ietf-ancp-protocol : = Containing the=20 solutions for the Topology discovery, line configuration and OAM = use=20 cases
Multicast extensions = draft:=20 Containing the transactional multicast solution and all of the = content of=20 draft-lefaucheur

This would allow us to move forward = with WG LC=20 on the basic use case solutions, and also keep all of the = multicast=20 extensions in a single draft.

Please can you indicate to the list = whether you=20 support this proposal.

Regards

Matthew=20 =


_______________________________________________
ANCP=20 mailing list
ANCP@ietf.org
https://www.ietf.org/= mailman/listinfo/ancp


------_=_NextPart_001_01C9E82A.F47A61C9-- From Matthew.Bocci@alcatel-lucent.com Mon Jun 8 22:34:46 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A848F3A6B58 for ; Mon, 8 Jun 2009 22:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4quk-zJRinf for ; Mon, 8 Jun 2009 22:34:45 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id EB6F83A67D7 for ; Mon, 8 Jun 2009 22:34:44 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n595YjIb006620; Tue, 9 Jun 2009 07:34:45 +0200 Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.36]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 07:34:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9E8C3.FED96CD7" Date: Tue, 9 Jun 2009 07:34:43 +0200 Message-ID: <0458D2EE0C36744BABB36BE37805C29A03EC4066@FRVELSMBS11.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Splitting multicast from protocol doc Thread-Index: AcnoJVxyUXMHZkalQ06aQ8KRpNNWwgAAwNeAACbKulA= References: <0458D2EE0C36744BABB36BE37805C29A039300AF@FRVELSMBS11.ad2.ad.alcatel.com> <671A5BF3-6386-4741-84C2-5B3051D77DAA@cisco.com> From: "BOCCI Matthew" To: "Wojciech Dec (wdec)" , "Francois Le Faucheur (flefauch)" , "Maglione Roberta" X-OriginalArrivalTime: 09 Jun 2009 05:34:45.0643 (UTC) FILETIME=[FF4F65B0:01C9E8C3] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: ancp@ietf.org Subject: Re: [ANCP] Splitting multicast from protocol doc X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 05:34:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9E8C3.FED96CD7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I only actually saw one against for splitting the mcast text from the ANCP protocol spec. However, I accept that it may not be that easy to split it out. =20 I am fine with the approach below, so long as the ANCP base protocol spec can stand alone and that it is not necessary to implement the mcast spec to support the base mcast functions in the ANCP protocol spec. =20 Matthew =20 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: 08 June 2009 12:19 To: Francois Le Faucheur (flefauch); BOCCI Matthew; Maglione Roberta Cc: ancp@ietf.org Subject: RE: [ANCP] Splitting multicast from protocol doc =20 Hi Francois, =20 let's go with the this approach. Some delicate surgery is needed on the ancp-protocol draft to move the mcast specific parts to the new ID, but leave the base protocol parts that have been defined (or re-defined) as part of the mcast work in the base protocol spec. A rough line to draw would be: - ANCP base header definitions, extensions -> ancp-protocol - Mcast capability negotiation, messages, message flows, error codes -> mcast ID There are some provisioning aspects of the mcast use-cases (eg the lists) that likely could apply to the wider provisioning use-case, so this could go either way. =20 It would seem like having the editors of both docs discuss the what goes where would be a good next step. =20 Regards, Woj. =20 =09 ________________________________ From: Francois Le Faucheur (flefauch)=20 Sent: 08 June 2009 12:39 To: BOCCI Matthew; Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: Re: [ANCP] Splitting multicast from protocol doc Matthew, Woj,=20 =20 We had a few responses to this proposal. What is the final decision? =20 Thanks =20 Francois =20 On 31 Mar 2009, at 22:21, Francois Le Faucheur IMAP wrote: =09 =09 =09 support.=20 Francois =20 On 31 Mar 2009, at 17:46, BOCCI Matthew wrote: =09 =09 =09 There was a proposal at the last IETF to take the multicast text from draft-ietf-ancp-protocol-05 and merge it with draft-lefaucheur-ancp-mc-extensions-01. We would thus have two protocol drafts:=20 draft-ietf-ancp-protocol : Containing the solutions for the Topology discovery, line configuration and OAM use cases=20 Multicast extensions draft: Containing the transactional multicast solution and all of the content of draft-lefaucheur=20 This would allow us to move forward with WG LC on the basic use case solutions, and also keep all of the multicast extensions in a single draft. Please can you indicate to the list whether you support this proposal.=20 Regards=20 Matthew=20 =20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp =20 =20 ------_=_NextPart_001_01C9E8C3.FED96CD7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I only actually saw one against for splitting the mcast text from the ANCP protocol spec. However, I accept = that it may not be that easy to split it out.

 

I am fine with the approach below, = so long as the ANCP base protocol spec can stand alone and that it is not = necessary to implement the mcast spec to support the base mcast functions in the ANCP protocol spec.

 

Matthew

=

 

From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]
Sent: 08 June 2009 = 12:19
To: Francois Le Faucheur (flefauch); BOCCI Matthew; Maglione Roberta
Cc: ancp@ietf.org
Subject: RE: [ANCP] = Splitting multicast from protocol doc

 

Hi Francois,

 

let's go with the this approach. Some delicate = surgery is needed on the ancp-protocol draft to move the mcast specific parts to = the new ID, but leave the base protocol parts that have been defined (or re-defined) as part of the mcast work in the base protocol spec. A = rough line to draw would be:

- ANCP base header definitions, extensions -> ancp-protocol

- Mcast capability negotiation, messages, message flows, error codes -> mcast ID

There are some provisioning aspects of the mcast = use-cases (eg the lists) that likely could apply to the wider provisioning = use-case, so this could go either way.

 

It would seem like having the editors of both docs discuss the what goes where would be a good next = step.

 

Regards,

Woj.

 

From: Francois Le Faucheur (flefauch)
Sent: 08 June 2009 = 12:39
To: BOCCI Matthew; = Wojciech Dec (wdec)
Cc: ancp@ietf.org
Subject: Re: [ANCP] = Splitting multicast from protocol doc

Matthew, Woj,

 

We had a few responses to this proposal. What is the final = decision?

 

Thanks

 

Francois

 

On 31 Mar 2009, at 22:21, Francois Le Faucheur IMAP = wrote:



support.

Francois

 

On 31 Mar 2009, at 17:46, BOCCI Matthew = wrote:



There was a proposal at the last IETF to take the multicast text from draft-ietf-ancp-protocol-05 and merge it with draft-lefaucheur-ancp-mc-extensions-01.

We would thus have two protocol drafts:

draft-ietf-ancp-protocol : Containing the solutions for the Topology discovery, line = configuration and OAM use cases
Multicast extensions draft: Containing the transactional multicast solution and = all of the content of draft-lefaucheur

This would allow us to move forward with WG LC on the basic use case = solutions, and also keep all of the multicast extensions in a single = draft.

Please can you indicate to the list whether you support this = proposal.

Regards

Matthew

 

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www.ietf.org/= mailman/listinfo/ancp

 

 

------_=_NextPart_001_01C9E8C3.FED96CD7-- From roberta.maglione@telecomitalia.it Thu Jun 11 02:49:58 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5DE93A6D61 for ; Thu, 11 Jun 2009 02:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ce21FROb0zO7 for ; Thu, 11 Jun 2009 02:49:50 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id BD0A33A696C for ; Thu, 11 Jun 2009 02:49:49 -0700 (PDT) Content-Type: multipart/mixed; boundary="_c140d1a3-2f4c-407c-8b28-905c2703aad8_" Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 11 Jun 2009 11:49:55 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Thu, 11 Jun 2009 11:49:54 +0200 From: Maglione Roberta To: 'BOCCI Matthew' , "Wojciech Dec (wdec)" , "Francois Le Faucheur (flefauch)" Date: Thu, 11 Jun 2009 11:49:54 +0200 Thread-Topic: [ANCP] Splitting multicast from protocol doc Thread-Index: AcnoJVxyUXMHZkalQ06aQ8KRpNNWwgAAwNeAACbKulAAbPXrUA== Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3E60EF3566@GRFMBX704BA020.griffon.local> References: <0458D2EE0C36744BABB36BE37805C29A039300AF@FRVELSMBS11.ad2.ad.alcatel.com> <671A5BF3-6386-4741-84C2-5B3051D77DAA@cisco.com> <0458D2EE0C36744BABB36BE37805C29A03EC4066@FRVELSMBS11.ad2.ad.alcatel.com> In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A03EC4066@FRVELSMBS11.ad2.ad.alcatel.com> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT MIME-Version: 1.0 Cc: "ancp@ietf.org" Subject: Re: [ANCP] Splitting multicast from protocol doc X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 09:49:58 -0000 --_c140d1a3-2f4c-407c-8b28-905c2703aad8_ Content-Type: multipart/alternative; boundary="_000_282BBE8A501E1F4DA9C775F964BB21FE3E60EF3566GRFMBX704BA02_" --_000_282BBE8A501E1F4DA9C775F964BB21FE3E60EF3566GRFMBX704BA02_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Woj, I'm not sure I've fully understood your proposal about splitting the w= ork between the two documents: > - ANCP base header definitions, extensions -> ancp-protocol =3D =3D> in my understanding this is the text from section 5.4.5, isn't it? However if we move the multicast messages and the error codes in the other = draft why should we leave in the base protocol the ANCP base header definit= ion? The ANCP message format defined in section 5.4.5 is currently used onl= y for Multicast messages (mcast replication control message and mcast statu= s message) thus if we move these messages out of base protocol drafts shoul= dn't we move also the ANCP base header specification? The only reason I thought about is because when we defined multicast messag= es we introduced a new approach/logic for message semantic: instead of re-u= sing the same message for request and response with different result code w= e used two different messages for request and response and we added the res= ult code =3D0 (ignore) semantic. Is the specification of this behavior that= you are suggesting to keep in the base protocol draft in order to have thi= s approach available in future for other messages definitions? >- Mcast capability negotiation, messages, message flows, error codes -> mc= ast ID Thanks, Regards Roberta ________________________________ From: BOCCI Matthew [mailto:Matthew.Bocci@alcatel-lucent.com] Sent: Tuesday, June 09, 2009 7:35 AM To: Wojciech Dec (wdec); Francois Le Faucheur (flefauch); Maglione Roberta Cc: ancp@ietf.org Subject: RE: [ANCP] Splitting multicast from protocol doc I only actually saw one against for splitting the mcast text from the ANCP = protocol spec. However, I accept that it may not be that easy to split it o= ut. I am fine with the approach below, so long as the ANCP base protocol spec c= an stand alone and that it is not necessary to implement the mcast spec to = support the base mcast functions in the ANCP protocol spec. Matthew ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: 08 June 2009 12:19 To: Francois Le Faucheur (flefauch); BOCCI Matthew; Maglione Roberta Cc: ancp@ietf.org Subject: RE: [ANCP] Splitting multicast from protocol doc Hi Francois, let's go with the this approach. Some delicate surgery is needed on the anc= p-protocol draft to move the mcast specific parts to the new ID, but leave = the base protocol parts that have been defined (or re-defined) as part of t= he mcast work in the base protocol spec. A rough line to draw would be: - ANCP base header definitions, extensions -> ancp-protocol - Mcast capability negotiation, messages, message flows, error codes -> mca= st ID There are some provisioning aspects of the mcast use-cases (eg the lists) t= hat likely could apply to the wider provisioning use-case, so this could go= either way. It would seem like having the editors of both docs discuss the what goes wh= ere would be a good next step. Regards, Woj. ________________________________ From: Francois Le Faucheur (flefauch) Sent: 08 June 2009 12:39 To: BOCCI Matthew; Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: Re: [ANCP] Splitting multicast from protocol doc Matthew, Woj, We had a few responses to this proposal. What is the final decision? Thanks Francois On 31 Mar 2009, at 22:21, Francois Le Faucheur IMAP wrote: support. Francois On 31 Mar 2009, at 17:46, BOCCI Matthew wrote: There was a proposal at the last IETF to take the multicast text from draft= -ietf-ancp-protocol-05 and merge it with draft-lefaucheur-ancp-mc-extension= s-01. We would thus have two protocol drafts: draft-ietf-ancp-protocol : Containing the solutions for the Topology discov= ery, line configuration and OAM use cases Multicast extensions draft: Containing the transactional multicast solution= and all of the content of draft-lefaucheur This would allow us to move forward with WG LC on the basic use case soluti= ons, and also keep all of the multicast extensions in a single draft. Please can you indicate to the list whether you support this proposal. Regards Matthew _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne 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, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000001@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non ? necessario. --_000_282BBE8A501E1F4DA9C775F964BB21FE3E60EF3566GRFMBX704BA02_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Woj,

&nb= sp;    I’m not sure I’ve fully understood your p= roposal about splitting the work between the two documents:

&nb= sp;

> - ANCP base header definitions, extensions&n= bsp;-> ancp-protocol

=3D =3D> in my understanding= this is the text from section 5.4.5, isn’t= it?

How= ever if we move the multicast messages and the error codes in the other dra= ft why should we leave in the base protocol the ANCP base header definition? The ANCP message format defined in sectio= n 5.4.5 is currently used only for Multicast messages (mcast replication co= ntrol message and mcast status message) thus if we move these messages out = of base protocol drafts shouldn’t we move also the ANCP base header specification? =

The= only reason I thought about is because when we defined multicast messages = we introduced a new approach/logic for message semantic: instead of re-using the same message for request and response wi= th different result code we used two different messages for request and res= ponse and we added the result code =3D0 (ignore) semantic. Is the specifica= tion of this behavior that you are suggesting to keep in the base protocol draft in order to have this approa= ch available in future for other messages definitions?  

 

>- Mcast capability negotiation, messages, mes= sage flows, error codes -> mcast ID

 

Tha= nks,

Reg= ards

Rob= erta

From: BOCCI Matthew [mailto:Matthew.= Bocci@alcatel-lucent.com]
Sent: Tuesday, June 09, 2009= 7:35 AM
To: Wojciech Dec (wdec); Fra= ncois Le Faucheur (flefauch); Maglione Roberta
Cc: ancp@ietf.org
Subject: RE: [ANCP] Splittin= g multicast from protocol doc=

 

I o= nly actually saw one against for splitting the mcast text from the ANCP pro= tocol spec. However, I accept that it may not be that easy to split it out.

 

I a= m fine with the approach below, so long as the ANCP base protocol spec can = stand alone and that it is not necessary to implement the mcast spec to support the base mcast functions in the ANCP p= rotocol spec.

 

Mat= thew

 

From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]
Sent: 08 June 2009 12:19
To: Francois Le Faucheur (fl= efauch); BOCCI Matthew; Maglione Robert= a
Cc: ancp@ietf.org
Subject: RE: [ANCP] Splittin= g multicast from protocol doc=

 

Hi Francois,

 

let's go with the this approach. Some delicate su= rgery is needed on the ancp-protocol draft to move the mcast specific parts= to the new ID, but leave the base protocol parts that have been defined (or re-defined) = as part of the mcast work in the base protocol spec. A rough line to draw w= ould be:

- ANCP base header definitions, extensions -= > ancp-protocol

- Mcast capability negotiation, messages, message= flows, error codes -> mcast ID<= o:p>

There are some provisioning aspects of the mcast = use-cases (eg the lists) that likely could apply to the wider provisioning = use-case, so this could go either way.

 

It would seem like having the editors of both doc= s discuss the what goes where would be a good next step.=

 

Regards,<= /o:p>

Woj.

 

From: Francois Le Faucheur (flefauch)
Sent: 08 June 2009 12:39
To: BOCCI Matthew; Wojciech Dec (wdec)
Cc: ancp@ietf.org
Subject: Re: [ANCP] Splittin= g multicast from protocol doc=

Matthew, Woj,

 

We had a few responses to this propos= al. What is the final decision?

 

Thanks

 

Francois

 

On 31 Mar 2009, at 22:21, Francois Le= Faucheur IMAP wrote:

&= nbsp;

support.

Francois

 

On 31 Mar 2009, at 17:46, BOCCI Matthew wrote:

&= nbsp;

There was a proposal at the last IETF to take the multicast text fro= m draft-ietf-ancp-protocol-05 and merge it with draft-lefaucheur-ancp-mc-ex= tensions-01.

We would thus have two protocol drafts:

draft-ietf-ancp-protocol : Containing the solutions for the Topology= discovery, line configuration and OAM use cases
Multicast extensions draft: Containing the transactional= multicast solution and all of the content of draft-lefaucheur

This would allow us to move forward with WG LC on the basic use case= solutions, and also keep all of the multicast extensions in a single draft= .

Please can you indicate to the list whether you support this proposa= l.

Regards

Matthew

 

_____________________________________= __________
ANCP mailing list
ANCP@ietf.org
https://www.ietf.org= /mailman/listinfo/ancp

 

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere 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. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non è necessario.

--_000_282BBE8A501E1F4DA9C775F964BB21FE3E60EF3566GRFMBX704BA02_-- --_c140d1a3-2f4c-407c-8b28-905c2703aad8_ Content-Description: logo Ambiente_foglia.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000001@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_c140d1a3-2f4c-407c-8b28-905c2703aad8_-- From roberta.maglione@telecomitalia.it Thu Jun 11 03:01:21 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81FD23A684F for ; Thu, 11 Jun 2009 03:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.581 X-Spam-Level: X-Spam-Status: No, score=0.581 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ym0GFi7jg44W for ; Thu, 11 Jun 2009 03:01:20 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 727F23A6843 for ; Thu, 11 Jun 2009 03:01:20 -0700 (PDT) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 11 Jun 2009 12:01:26 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Thu, 11 Jun 2009 12:01:25 +0200 From: Maglione Roberta To: "ancp@ietf.org" Date: Thu, 11 Jun 2009 12:01:25 +0200 Thread-Topic: Adjacency keep-alives Thread-Index: Acnqe5RRFOboMUEBQwm1hZXFrinbPA== Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3E60EF3567@GRFMBX704BA020.griffon.local> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ANCP] Adjacency keep-alives X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 10:01:21 -0000 Hello, in San Francisco we started a discussion on Adjacency keep-alives. Possible problem: the mismatched timers between peers. One proposed approach was to make keepalive timer be negotiable. Could you please provide your feedback and comments on this proposal? Thanks and best regards, Roberta Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne 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, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From flefauch@cisco.com Thu Jun 11 06:01:08 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E9FB28C0D9 for ; Thu, 11 Jun 2009 06:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.9 X-Spam-Level: X-Spam-Status: No, score=-9.9 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RL2gSUSYyde for ; Thu, 11 Jun 2009 06:01:06 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 272833A6821 for ; Thu, 11 Jun 2009 06:01:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,202,1243814400"; d="scan'208,217";a="42589785" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Jun 2009 13:01:11 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5BD1Bbc018444; Thu, 11 Jun 2009 15:01:11 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5BD1Bfs017387; Thu, 11 Jun 2009 13:01:11 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jun 2009 15:01:11 +0200 Received: from ams-flefauch-8713.cisco.com ([10.55.161.196]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jun 2009 15:01:09 +0200 Message-Id: <5DAF167E-64F2-4CD6-A230-709B0920CC1C@cisco.com> From: Francois Le Faucheur IMAP To: BOCCI Matthew , "Wojciech Dec (wdec)" In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3E60EF3566@GRFMBX704BA020.griffon.local> Content-Type: multipart/alternative; boundary=Apple-Mail-9-130095436 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 11 Jun 2009 15:01:07 +0200 References: <0458D2EE0C36744BABB36BE37805C29A039300AF@FRVELSMBS11.ad2.ad.alcatel.com> <671A5BF3-6386-4741-84C2-5B3051D77DAA@cisco.com> <0458D2EE0C36744BABB36BE37805C29A03EC4066@FRVELSMBS11.ad2.ad.alcatel.com> <282BBE8A501E1F4DA9C775F964BB21FE3E60EF3566@GRFMBX704BA020.griffon.local> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 11 Jun 2009 13:01:09.0805 (UTC) FILETIME=[B0BDADD0:01C9EA94] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=41389; t=1244725271; x=1245589271; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[ANCP]=20Splitting=20multicast=20from=2 0protocol=20doc |Sender:=20; bh=RjX6JMFmAPYpMDeM+YA8L+X/IFSpIqe1NIDjuAKANlg=; b=w0pJrI5c8YnUwvKcVBZ0fCXDN0GzDSWTXkp4MWN/mSJ9ChvJeC1s9cmpOK hGz4oconAB+/n3Klhw47DRve23KPPW1EU2MHirvhlnwpMfs9D6LjbcNmHgcI YouAX8xBOq; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ancp@ietf.org Subject: Re: [ANCP] Splitting multicast from protocol doc X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 13:01:08 -0000 --Apple-Mail-9-130095436 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hello, Just had a quick chat with Roberta. Regarding the ANCP base header: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D I think what Woj is proposing is that: * ancp-proto: - keeps a small section that introduce the notion that = some ANCP =20 message may be ANCP-specific non-GSMP message types - defines the based header for such messages (ie what is = currently =20 at the beginning of 5.4.5 ) * ancp-multicast: - refers to ancp-proto for the definition of ANCP base = header - defines multicats messages using this ANCP base header Is that right Woj? That would work for me & Roberta. Is this OK to all? Regarding Provisioning =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We could move the definition of the Provisioning message into ancp-=20 proto. ancp-mcast woudl then define the TLVs that are relevant for =20 provisioning of multicast and that woudl be carried inside the =20 Provisioning message defined in ancp-proto. Note that there is currently no TLVs defined for teh provisioning of =20 non-multicast things. So even if the Provisioning message is defined =20 inside ancp-proto it wouldn't, for now, be of real use for ancp-proto. =20= But still that seems like the right place to define the message itself. Is this OK to all? Francois PS: in line with Woj suggestion, i sent an invite for editors of the =20 two docs to discuss. On 11 Jun 2009, at 11:49, Maglione Roberta wrote: > Hi Woj, > I=92m not sure I=92ve fully understood your proposal about =20 > splitting the work between the two documents: > > > - ANCP base header definitions, extensions -> ancp-protocol > =3D =3D> in my understanding this is the text from section 5.4.5, = isn=92t =20 > it? > However if we move the multicast messages and the error codes in the =20= > other draft why should we leave in the base protocol the ANCP base =20 > header definition? The ANCP message format defined in section 5.4.5 =20= > is currently used only for Multicast messages (mcast replication =20 > control message and mcast status message) thus if we move these =20 > messages out of base protocol drafts shouldn=92t we move also the ANCP = =20 > base header specification? > The only reason I thought about is because when we defined multicast =20= > messages we introduced a new approach/logic for message semantic: =20 > instead of re-using the same message for request and response with =20 > different result code we used two different messages for request and =20= > response and we added the result code =3D0 (ignore) semantic. Is the =20= > specification of this behavior that you are suggesting to keep in =20 > the base protocol draft in order to have this approach available in =20= > future for other messages definitions? > > >- Mcast capability negotiation, messages, message flows, error =20 > codes -> mcast ID > > Thanks, > Regards > Roberta > From: BOCCI Matthew [mailto:Matthew.Bocci@alcatel-lucent.com] > Sent: Tuesday, June 09, 2009 7:35 AM > To: Wojciech Dec (wdec); Francois Le Faucheur (flefauch); Maglione =20 > Roberta > Cc: ancp@ietf.org > Subject: RE: [ANCP] Splitting multicast from protocol doc > > I only actually saw one against for splitting the mcast text from =20 > the ANCP protocol spec. However, I accept that it may not be that =20 > easy to split it out. > > I am fine with the approach below, so long as the ANCP base protocol =20= > spec can stand alone and that it is not necessary to implement the =20 > mcast spec to support the base mcast functions in the ANCP protocol =20= > spec. > > Matthew > > From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > Sent: 08 June 2009 12:19 > To: Francois Le Faucheur (flefauch); BOCCI Matthew; Maglione Roberta > Cc: ancp@ietf.org > Subject: RE: [ANCP] Splitting multicast from protocol doc > > Hi Francois, > > let's go with the this approach. Some delicate surgery is needed on =20= > the ancp-protocol draft to move the mcast specific parts to the new =20= > ID, but leave the base protocol parts that have been defined (or re-=20= > defined) as part of the mcast work in the base protocol spec. A =20 > rough line to draw would be: > - ANCP base header definitions, extensions -> ancp-protocol > - Mcast capability negotiation, messages, message flows, error codes =20= > -> mcast ID > There are some provisioning aspects of the mcast use-cases (eg the =20 > lists) that likely could apply to the wider provisioning use-case, =20 > so this could go either way. > > It would seem like having the editors of both docs discuss the what =20= > goes where would be a good next step. > > Regards, > Woj. > > From: Francois Le Faucheur (flefauch) > Sent: 08 June 2009 12:39 > To: BOCCI Matthew; Wojciech Dec (wdec) > Cc: ancp@ietf.org > Subject: Re: [ANCP] Splitting multicast from protocol doc > Matthew, Woj, > > We had a few responses to this proposal. What is the final decision? > > Thanks > > Francois > > On 31 Mar 2009, at 22:21, Francois Le Faucheur IMAP wrote: > > support. > Francois > > On 31 Mar 2009, at 17:46, BOCCI Matthew wrote: > > There was a proposal at the last IETF to take the multicast text =20 > from draft-ietf-ancp-protocol-05 and merge it with draft-lefaucheur-=20= > ancp-mc-extensions-01. > > We would thus have two protocol drafts: > > draft-ietf-ancp-protocol : Containing the solutions for the Topology =20= > discovery, line configuration and OAM use cases > Multicast extensions draft: Containing the transactional multicast =20 > solution and all of the content of draft-lefaucheur > > This would allow us to move forward with WG LC on the basic use case =20= > solutions, and also keep all of the multicast extensions in a single =20= > draft. > > Please can you indicate to the list whether you support this proposal. > > Regards > > Matthew > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente =20 > alle persone indicate. La diffusione, copia o qualsiasi altra azione =20= > derivante dalla conoscenza di queste informazioni sono rigorosamente =20= > vietate. Qualora abbiate ricevuto questo documento per errore siete =20= > cortesemente pregati di darne immediata comunicazione al mittente e =20= > di provvedere alla sua distruzione, Grazie. > This e-mail and any attachments is confidential and may contain =20 > privileged information intended for the addressee(s) only. =20 > Dissemination, copying, printing or use by anybody else is =20 > unauthorised. If you are not the intended recipient, please delete =20 > this message and any attachments and advise the sender by return e-=20 > mail, Thanks. > > Rispetta l'ambiente. Non stampare questa =20 > mail se non =E8 necessario. > > --Apple-Mail-9-130095436 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hello,

Just = had a quick chat with Roberta.

Regarding the = ANCP base header:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I think what Woj is proposing = is that:
* ancp-proto:
= - keeps a small section that introduce the notion that some = ANCP message may be ANCP-specific non-GSMP message = types
- defines the based = header for such messages (ie what is currently = at the beginning of 5.4.5 )
* = ancp-multicast:
- refers to ancp-proto = for the definition of ANCP base header
- = defines multicats messages using this ANCP base header
Is = that right Woj?
That would work for me & = Roberta. Is this OK to = all?


Regarding = Provisioning
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
We could move the definition of the Provisioning message into = ancp-proto. ancp-mcast woudl then define the TLVs that are relevant for = provisioning of multicast and that woudl be carried inside the = Provisioning message defined in ancp-proto.
Note that there is = currently no TLVs defined for teh provisioning of non-multicast things. = So even if the Provisioning message is defined inside ancp-proto it = wouldn't, for now, be of real use for ancp-proto. But still that seems = like the right place to define the message = itself.
Is this OK to = all?

Francois

PS: in = line with Woj suggestion, i sent an invite for editors of the two docs = to discuss.

On 11 Jun 2009, at 11:49, Maglione = Roberta wrote:

Hi = Woj,
     I=92m not = sure I=92ve fully understood your proposal about splitting the work = between the two documents:
 
> - ANCP base header definitions, = extensions -> ancp-protocol
=3D =3D> in my understanding this is the text from section 5.4.5, isn=92t = it?
However if we move the = multicast messages and the error codes in the other draft why should we = leave in the base protocol the ANCP base header definition? The ANCP = message format defined in section 5.4.5 is currently used only for = Multicast messages (mcast replication control message and mcast status = message) thus if we move these messages out of base protocol drafts = shouldn=92t we move also the ANCP base header = specification?
The only reason I thought about = is because when we defined multicast messages we introduced a new = approach/logic for message semantic: instead of re-using the same = message for request and response with different result code we used two = different messages for request and response and we added the result code = =3D0 (ignore) semantic. Is the specification of this behavior that you = are suggesting to keep in the base protocol draft in order to have this = approach available in future for other messages definitions? =  
>- Mcast capability negotiation, messages, message = flows, error codes -> mcast ID
From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] 
Sent: 08 June 2009 = 12:19
To: Francois Le Faucheur = (flefauch); BOCCI Matthew; Maglione Roberta
Cc: Subject: RE: [ANCP] Splitting = multicast from protocol doc
There was a proposal at the last IETF to = take the multicast text from draft-ietf-ancp-protocol-05 and merge it = with draft-lefaucheur-ancp-mc-extensions-01.

We would thus have two protocol = drafts:

 
Multicast extensions draft: Containing the = transactional multicast solution and all of the content of = draft-lefaucheur

This would allow us to move forward with WG = LC on the basic use case solutions, and also keep all of the multicast = extensions in a single draft.

Please can you indicate to the list whether = you support this proposal.

Regards

Matthew

ANCP@ietf.org
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.

<logo = Ambiente_foglia.jpg>Rispetta l'ambiente. Non stampare questa mail = se non =E8 necessario.

&= lt;logo = Ambiente_foglia.jpg>

= --Apple-Mail-9-130095436-- From wdec@cisco.com Thu Jun 11 06:33:58 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2D013A6A7C for ; Thu, 11 Jun 2009 06:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QdO9Uuv6Tuz for ; Thu, 11 Jun 2009 06:33:56 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 504C23A6A7B for ; Thu, 11 Jun 2009 06:33:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,202,1243814400"; d="scan'208,217";a="42594238" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 11 Jun 2009 13:34:01 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5BDY14m008882; Thu, 11 Jun 2009 15:34:01 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5BDY1LF029159; Thu, 11 Jun 2009 13:34:01 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jun 2009 15:34:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EA99.47A9D296" Date: Thu, 11 Jun 2009 15:33:56 +0200 Message-ID: In-Reply-To: <5DAF167E-64F2-4CD6-A230-709B0920CC1C@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Splitting multicast from protocol doc Thread-Index: AcnqlLG3AADepa8zTkmPjQ0v9MgEIQAA9TwA References: <0458D2EE0C36744BABB36BE37805C29A039300AF@FRVELSMBS11.ad2.ad.alcatel.com> <671A5BF3-6386-4741-84C2-5B3051D77DAA@cisco.com> <0458D2EE0C36744BABB36BE37805C29A03EC4066@FRVELSMBS11.ad2.ad.alcatel.com> <282BBE8A501E1F4DA9C775F964BB21FE3E60EF3566@GRFMBX704BA020.griffon.local> <5DAF167E-64F2-4CD6-A230-709B0920CC1C@cisco.com> From: "Wojciech Dec (wdec)" To: "Francois Le Faucheur (flefauch)" , "BOCCI Matthew" X-OriginalArrivalTime: 11 Jun 2009 13:34:01.0664 (UTC) FILETIME=[480F7C00:01C9EA99] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=43274; t=1244727241; x=1245591241; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20Splitting=20multicast=20from=2 0protocol=20doc |Sender:=20; bh=zTOgd6p85LeYIzgJjs6ihZg+vEpgBkq36UFtlDeN5ow=; b=WVzCi/FecSb7lgMCgRqlsj/+ERFkroFy50kQX3R9id0PS/i3n9DAGSouqo MgUws4jCnuezdQsZZJPFTRrJnMl7jc7q3Uuv3j3GJYZlQBhswErAjwHBK0t9 L371eerlqu; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ancp@ietf.org Subject: Re: [ANCP] Splitting multicast from protocol doc X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 13:33:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EA99.47A9D296 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 ________________________________ From: Francois Le Faucheur (flefauch)=20 Sent: 11 June 2009 15:01 To: BOCCI Matthew; Wojciech Dec (wdec) Cc: Maglione Roberta; Francois Le Faucheur (flefauch); ancp@ietf.org; = Sanjay Wadhwa Subject: Re: [ANCP] Splitting multicast from protocol doc =09 =09 Hello,=20 Just had a quick chat with Roberta. Regarding the ANCP base header: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D I think what Woj is proposing is that: * ancp-proto: - keeps a small section that introduce the notion that some ANCP = message may be ANCP-specific non-GSMP message types =09 - defines the based header for such messages (ie what is currently at = the beginning of 5.4.5 )=20 * ancp-multicast: - refers to ancp-proto for the definition of ANCP base header =09 - defines multicats messages using this ANCP base header =09 Is that right Woj?=20 =20 Woj> Yes, that's it, noting that if people see a better way to = cut-it-up, then please do come forward with your opinions. One other thing to consider adding to the ancp-multicast draft is of = course the capability extension code point(s), with the capability = extension mechanism (negotiation?) defined in the ancp-protocol draft. =20 That would work for me & Roberta. Is this OK to all? Regarding Provisioning =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We could move the definition of the Provisioning message into = ancp-proto. ancp-mcast woudl then define the TLVs that are relevant for = provisioning of multicast and that woudl be carried inside the = Provisioning message defined in ancp-proto. Note that there is currently no TLVs defined for teh provisioning of = non-multicast things. So even if the Provisioning message is defined = inside ancp-proto it wouldn't, for now, be of real use for ancp-proto. = But still that seems like the right place to define the message itself. Is this OK to all?=20 =20 Woj> Works for me. =20 Regards, Woj.=20 Francois PS: in line with Woj suggestion, i sent an invite for editors of the = two docs to discuss. On 11 Jun 2009, at 11:49, Maglione Roberta wrote: =09 Hi Woj, I'm not sure I've fully understood your proposal about splitting = the work between the two documents: =09 > - ANCP base header definitions, extensions -> ancp-protocol =3D =3D> in my understanding this is the text from section 5.4.5, = isn't it? However if we move the multicast messages and the error codes in the = other draft why should we leave in the base protocol the ANCP base = header definition? The ANCP message format defined in section 5.4.5 is = currently used only for Multicast messages (mcast replication control = message and mcast status message) thus if we move these messages out of = base protocol drafts shouldn't we move also the ANCP base header = specification? The only reason I thought about is because when we defined multicast = messages we introduced a new approach/logic for message semantic: = instead of re-using the same message for request and response with = different result code we used two different messages for request and = response and we added the result code =3D0 (ignore) semantic. Is the = specification of this behavior that you are suggesting to keep in the = base protocol draft in order to have this approach available in future = for other messages definitions? =20 =09 >- Mcast capability negotiation, messages, message flows, error codes = -> mcast ID =09 Thanks, Regards Roberta =09 ________________________________ From: BOCCI Matthew [mailto:Matthew.Bocci@alcatel-lucent.com]=20 Sent: Tuesday, June 09, 2009 7:35 AM To: Wojciech Dec (wdec); Francois Le Faucheur (flefauch); Maglione = Roberta Cc: ancp@ietf.org Subject: RE: [ANCP] Splitting multicast from protocol doc =09 I only actually saw one against for splitting the mcast text from the = ANCP protocol spec. However, I accept that it may not be that easy to = split it out. =09 I am fine with the approach below, so long as the ANCP base protocol = spec can stand alone and that it is not necessary to implement the mcast = spec to support the base mcast functions in the ANCP protocol spec. =09 Matthew =09 =09 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: 08 June 2009 12:19 To: Francois Le Faucheur (flefauch); BOCCI Matthew; Maglione Roberta Cc: ancp@ietf.org Subject: RE: [ANCP] Splitting multicast from protocol doc =09 Hi Francois, =09 let's go with the this approach. Some delicate surgery is needed on = the ancp-protocol draft to move the mcast specific parts to the new ID, = but leave the base protocol parts that have been defined (or re-defined) = as part of the mcast work in the base protocol spec. A rough line to = draw would be: - ANCP base header definitions, extensions -> ancp-protocol - Mcast capability negotiation, messages, message flows, error codes = -> mcast ID There are some provisioning aspects of the mcast use-cases (eg the = lists) that likely could apply to the wider provisioning use-case, so = this could go either way. =09 It would seem like having the editors of both docs discuss the what = goes where would be a good next step. =09 Regards, Woj. =09 =09 ________________________________ From: Francois Le Faucheur (flefauch)=20 Sent: 08 June 2009 12:39 To: BOCCI Matthew; Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: Re: [ANCP] Splitting multicast from protocol doc Matthew, Woj, =09 We had a few responses to this proposal. What is the final decision? =09 Thanks =09 Francois =09 On 31 Mar 2009, at 22:21, Francois Le Faucheur IMAP wrote: =09 support. Francois =09 On 31 Mar 2009, at 17:46, BOCCI Matthew wrote: =09 There was a proposal at the last IETF to take the multicast text from = draft-ietf-ancp-protocol-05 and merge it with = draft-lefaucheur-ancp-mc-extensions-01. We would thus have two protocol drafts: draft-ietf-ancp-protocol : Containing the solutions for the Topology = discovery, line configuration and OAM use cases=20 Multicast extensions draft: Containing the transactional multicast = solution and all of the content of draft-lefaucheur This would allow us to move forward with WG LC on the basic use case = solutions, and also keep all of the multicast extensions in a single = draft. Please can you indicate to the list whether you support this = proposal. Regards Matthew =09 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp =09 =09 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. Rispetta l'ambiente. Non stampare questa mail = se non =E8 necessario.=20 ------_=_NextPart_001_01C9EA99.47A9D296 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 

From: Francois Le Faucheur = (flefauch)=20
Sent: 11 June 2009 15:01
To: BOCCI Matthew; = Wojciech Dec=20 (wdec)
Cc: Maglione Roberta; Francois Le Faucheur = (flefauch);=20 ancp@ietf.org; Sanjay Wadhwa
Subject: Re: [ANCP] Splitting = multicast=20 from protocol doc

Hello,

Just had a quick chat with Roberta.

Regarding the ANCP base header:
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
I think what Woj is proposing is that:
*=20 ancp-proto:
- keeps a=20 small section that introduce the notion that some ANCP message may be=20 ANCP-specific non-GSMP message types
- defines=20 the based header for such messages (ie what is currently=20 at the beginning of 5.4.5 ) 
*=20 ancp-multicast:
- = refers to=20 ancp-proto for the definition of ANCP base header
- = defines=20 multicats messages using this ANCP base header
Is that right Woj? 
 
Woj> Yes,=20 that's it, noting that if people see a better way to cut-it-up, then = please do=20 come forward with your opinions.
One = other thing=20 to  consider adding to the ancp-multicast draft is of course the=20 capability extension code point(s), with the capability extension = mechanism=20 (negotiation?) defined in the ancp-protocol draft.
 
That would work for me & Roberta. Is this OK to = all?


Regarding Provisioning
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
We could move the definition of the Provisioning message into = ancp-proto.=20 ancp-mcast woudl then define the TLVs that are relevant for = provisioning of=20 multicast and that woudl be carried inside the Provisioning message = defined in=20 ancp-proto.
Note that there is currently no TLVs defined for teh provisioning = of=20 non-multicast things. So even if the Provisioning message is defined = inside=20 ancp-proto it wouldn't, for now, be of real use for ancp-proto. But = still that=20 seems like the right place to define the message = itself.
Is this OK to all? 
 
Woj> Works=20 for me.
 
Regards,
Woj. 

Francois

PS: in line with Woj suggestion, i sent an invite for editors of = the two=20 docs to discuss.

On 11 Jun 2009, at 11:49, Maglione Roberta wrote:
Hi=20 Woj,
    =20 I=92m not sure I=92ve fully understood your proposal about splitting = the work=20 between the two documents:
> - ANCP base = header=20 definitions, extensions ->=20 ancp-protocol
=3D =3D> in my understanding this is the text from section 5.4.5, isn=92t=20 it?
However = if we move=20 the multicast messages and the error codes in the other draft why = should we=20 leave in the base protocol the ANCP base header definition? The ANCP = message=20 format defined in section 5.4.5 is currently used only for Multicast = messages (mcast replication control message and mcast status = message) thus=20 if we move these messages out of base protocol drafts shouldn=92t we = move also=20 the ANCP base header specification?
The only = reason I=20 thought about is because when we defined multicast messages we = introduced a=20 new approach/logic for message semantic: instead of re-using the = same=20 message for request and response with different result code we used = two=20 different messages for request and response and we added the result = code =3D0=20 (ignore) semantic. Is the specification of this behavior that you = are=20 suggesting to keep in the base protocol draft in order to have this = approach=20 available in future for other messages definitions?=20  
 >- Mcast capability = negotiation, messages, message flows, error codes -> mcast=20 ID Thanks, Regards Roberta
From: BOCCI=20 Matthew [mailto:Matthew.Bocci@alc= atel-lucent.com] 
Sent: Tuesday, June 09, 2009 = 7:35=20 AM
To: Wojciech Dec (wdec); = Francois Le=20 Faucheur (flefauch); Maglione Roberta
Cc: ancp@ietf.org
Subject: RE: [ANCP] Splitting = multicast from=20 protocol doc
I only = actually saw=20 one against for splitting the mcast text from the ANCP protocol = spec.=20 However, I accept that it may not be that easy to split it=20 out. I am fine = with the=20 approach below, so long as the ANCP base protocol spec can stand = alone and=20 that it is not necessary to implement the mcast spec to support the = base=20 mcast functions in the ANCP protocol = spec. Matthew
From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] 
Sent: 08 June 2009 = 12:19
To: Francois Le Faucheur=20 (flefauch); BOCCI Matthew; Maglione = Roberta
Cc: ancp@ietf.org
Subject: RE: [ANCP] Splitting = multicast from=20 protocol doc
Hi = Francois, let's go with the this = approach.=20 Some delicate surgery is needed on the ancp-protocol draft to move = the mcast=20 specific parts to the new ID, but leave the base protocol parts that = have=20 been defined (or re-defined) as part of the mcast work in the = base=20 protocol spec. A rough line to draw would be: - ANCP base header = definitions,=20 extensions -> ancp-protocol - Mcast capability = negotiation,=20 messages, message flows, error codes -> mcast = ID There are some = provisioning=20 aspects of the mcast use-cases (eg the lists) that likely could = apply to the=20 wider provisioning use-case, so this could go either = way. It would seem like = having the=20 editors of both docs discuss the what goes where would be a = good next=20 step. Regards, Woj.
From: Francois Le Faucheur=20 (flefauch) 
Sent: 08 June 2009 = 12:39
To: BOCCI=20 Matthew; Wojciech Dec (wdec)
Cc: ancp@ietf.org
Subject: Re: [ANCP] Splitting = multicast=20 from protocol doc Matthew, = Woj,
We=20 had a few responses to this proposal. What is the final=20 decision?
Thanks
Francois
On=20 31 Mar 2009, at 22:21, Francois Le Faucheur IMAP=20 wrote:
support.
Francois
On=20 31 Mar 2009, at 17:46, BOCCI=20 Matthew wrote:
There was a proposal = at the=20 last IETF to take the multicast text from = draft-ietf-ancp-protocol-05 and=20 merge it with = draft-lefaucheur-ancp-mc-extensions-01.

We would thus have = two=20 protocol drafts:

draft-ietf-ancp-protocol :=20 Containing the solutions for the Topology discovery, line = configuration=20 and OAM use cases 
Multicast extensions = draft:=20 Containing the transactional multicast solution and all of the = content of=20 draft-lefaucheur

This would allow us = to move=20 forward with WG LC on the basic use case solutions, and also keep = all of=20 the multicast extensions in a single draft.

Please can you = indicate to the=20 list whether you support this proposal.

Regards

Matthew

_______________________________________________
ANCP=20 mailing list
ANCP@ietf.org
https://www.ietf.org/= mailman/listinfo/ancp
Questo = messaggio e i=20 suoi allegati sono indirizzati esclusivamente alle persone = indicate.=20 La diffusione, copia o qualsiasi altra azione derivante dalla=20 conoscenza di queste informazioni sono rigorosamente vietate. = Qualora=20 abbiate ricevuto questo documento per errore siete = cortesemente=20 pregati di darne immediata comunicazione al mittente e di = provvedere=20 alla sua distruzione, Grazie.
This e-mail = and any=20 attachments is confidential = and may=20 contain privileged information intended for the addressee(s) = only.=20 Dissemination, copying, printing or use by anybody else is=20 unauthorised. If you are not the intended recipient, please = delete=20 this message and any attachments and advise the sender by = return=20 e-mail, Thanks.

<logo=20 Ambiente_foglia.jpg>Rispetta l'ambiente. Non = stampare questa=20 mail se non =E8 necessario.
&l= t;logo=20 = Ambiente_foglia.jpg>=
------_=_NextPart_001_01C9EA99.47A9D296-- From Sidd.Aanand@ecitele.com Fri Jun 12 08:42:47 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3EA63A6DF4 for ; Fri, 12 Jun 2009 08:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBGesolZQmVi for ; Fri, 12 Jun 2009 08:42:47 -0700 (PDT) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id 8D0F13A6DD9 for ; Fri, 12 Jun 2009 08:42:46 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by ilptiron01.ecitele.com with ESMTP; 12 Jun 2009 18:38:56 +0300 Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 18:42:53 +0300 Received: from ilptextms01.ecitele.com (147.234.245.175) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server id 8.1.375.2; Fri, 12 Jun 2009 18:42:53 +0300 Received: from USPITMAIL02.ecitele.com ([10.0.0.30]) by ilptextms01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 18:42:53 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jun 2009 11:42:50 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Adjacency keep-alives thread-index: Acnqe5RRFOboMUEBQwm1hZXFrinbPAA+ArFg References: <282BBE8A501E1F4DA9C775F964BB21FE3E60EF3567@GRFMBX704BA020.griffon.local> From: Sidd Aanand To: "Maglione Roberta" , X-OriginalArrivalTime: 12 Jun 2009 15:42:53.0410 (UTC) FILETIME=[72F40C20:01C9EB74] Subject: Re: [ANCP] Adjacency keep-alives X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 15:42:47 -0000 Hello Roberta, After going through the minutes and the e-mail thread that started this discussion (http://www.ietf.org/mail-archive/web/ancp/current/msg00782.html), it looks to me that the easiest way to avoid mismatched timers is to adopt a simple scheme, where both ends look at the timer values in the received (initial) adjacency message and agree to use the higher of the two values. That is, the node that receives a higher timer value than its own, will reply in its subsequent adjacency messages (such as SYNACK, ACK) with the higher timer value.=20 There doesn't seem to be a need to add another capability. Having said the above, I should also add that we haven't seen any problems with asymmetric timers. So I am not sure what the exact problem is, but if we agree that we *need* to have symmetric timers, choosing a simple scheme such as the one mentioned above should suffice. Thanks, Sidd Aanand ECI Telecom. =20 -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Maglione Roberta Sent: Thursday, June 11, 2009 6:01 AM To: ancp@ietf.org Subject: [ANCP] Adjacency keep-alives Hello, in San Francisco we started a discussion on Adjacency keep-alives. Possible problem: the mismatched timers between peers. One proposed approach was to make keepalive timer be negotiable. Could you please provide your feedback and comments on this proposal? Thanks and best regards, Roberta 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 ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From wwwrun@core3.amsl.com Mon Jun 15 07:45:24 2009 Return-Path: X-Original-To: ancp@ietf.org Delivered-To: ancp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id CAF833A69D9; Mon, 15 Jun 2009 07:45:24 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090615144524.CAF833A69D9@core3.amsl.com> Date: Mon, 15 Jun 2009 07:45:24 -0700 (PDT) X-Mailman-Approved-At: Mon, 15 Jun 2009 08:22:55 -0700 Cc: ancp@ietf.org Subject: [ANCP] Last Call: draft-ietf-ancp-framework (Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks) to Informational RFC X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 14:45:24 -0000 The IESG has received a request from the Access Node Control Protocol WG (ancp) to consider the following document: - 'Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-06-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-10.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15270&rfc_flag=0 From wwwrun@core3.amsl.com Mon Jun 15 07:46:54 2009 Return-Path: X-Original-To: ancp@ietf.org Delivered-To: ancp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 6525828C14E; Mon, 15 Jun 2009 07:46:53 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090615144654.6525828C14E@core3.amsl.com> Date: Mon, 15 Jun 2009 07:46:54 -0700 (PDT) X-Mailman-Approved-At: Mon, 15 Jun 2009 08:22:55 -0700 Cc: ancp@ietf.org Subject: [ANCP] Last Call: draft-ietf-ancp-security-threats (Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)) to Informational RFC X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 14:46:54 -0000 The IESG has received a request from the Access Node Control Protocol WG (ancp) to consider the following document: - 'Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-06-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ancp-security-threats-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15580&rfc_flag=0 From flefauch@cisco.com Wed Jun 17 07:20:16 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA3C3A6E76 for ; Wed, 17 Jun 2009 07:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.432 X-Spam-Level: X-Spam-Status: No, score=-10.432 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXtmsfVkmlpf for ; Wed, 17 Jun 2009 07:20:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D1BC83A6AB9 for ; Wed, 17 Jun 2009 07:20:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,236,1243814400"; d="scan'208,217";a="43026873" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Jun 2009 14:20:22 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5HEKMKY012012; Wed, 17 Jun 2009 16:20:22 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5HEKM5c003076; Wed, 17 Jun 2009 14:20:22 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jun 2009 16:20:22 +0200 Received: from [144.254.53.207] ([144.254.53.207]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jun 2009 16:20:22 +0200 Message-Id: From: Francois Le Faucheur IMAP To: "Wojciech Dec (wdec)" , BOCCI Matthew , Maglione Roberta , Sanjay Wadhwa , "tom.taylor@rogers.com Taylor" In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-4-653248895 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 17 Jun 2009 16:20:21 +0200 References: <0458D2EE0C36744BABB36BE37805C29A039300AF@FRVELSMBS11.ad2.ad.alcatel.com> <671A5BF3-6386-4741-84C2-5B3051D77DAA@cisco.com> <0458D2EE0C36744BABB36BE37805C29A03EC4066@FRVELSMBS11.ad2.ad.alcatel.com> <282BBE8A501E1F4DA9C775F964BB21FE3E60EF3566@GRFMBX704BA020.griffon.local> <5DAF167E-64F2-4CD6-A230-709B0920CC1C@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 17 Jun 2009 14:20:22.0142 (UTC) FILETIME=[BFD541E0:01C9EF56] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=43738; t=1245248422; x=1246112422; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[ANCP]=20Splitting=20multicast=20from=2 0protocol=20doc |Sender:=20; bh=ztkXa/qGe42UVbR2hni4O6dQIKiJ59+R1k+24UQrn2Q=; b=GHXMfMuKKXEEkPTB3+6bkHREv850NTPsZ6arcSCjmQ9BS9C+9QjdyCnSVx nLS/97JwzqBAsbV04XUS3vBgpFQu7pSVfqCwHFJwGhSycPMAJ9+dCgNgOJaq vmdac833xW; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ancp@ietf.org Subject: Re: [ANCP] Splitting multicast from protocol doc X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 14:20:16 -0000 --Apple-Mail-4-653248895 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Folks, Sanjay, Roberta and I had a first chat. Our proposal is in line with =20 the thread below with a few more specifics described below: > > > Regarding the ANCP base header: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > I think what Woj is proposing is that: > * ancp-proto: > - keeps a small section that introduce the notion that some ANCP =20 > message may be ANCP-specific non-GSMP message types ancp-proto will include a section on "generic ANCP protocol mechanisms =20= for other uses cases". This will discuss: * alternate semantics for Transaction ID (as used by macst use = case) * notion of using different Message Types for a Response and the = =20 Request it is responding to (as used by mcast use case) * Well-Known TLVs (Target, Command, Status-Info) ancp-mcast will refer to the above section of ancp-proto when defining =20= the mcast specific messages/extensions. text from current section 5.4.5.2 and 5.4.5.3 (ie actual mcast =20 messages) will move to ancp-mcast. text from current section 4.4 (ie description of mcast use case) will =20= move to ancp-mcast (and be expanded to cover the other mcast use cases =20= than transactional mcast). > > - defines the based header for such messages (ie what is currently =20 > at the beginning of 5.4.5 ) > * ancp-multicast: > - refers to ancp-proto for the definition of ANCP base header > - defines multicats messages using this ANCP base header > Is that right Woj? > > Woj> Yes, that's it, noting that if people see a better way to cut-=20 > it-up, then please do come forward with your opinions. > One other thing to consider adding to the ancp-multicast draft is =20 > of course the capability extension code point(s), with the =20 > capability extension mechanism (negotiation?) defined in the ancp-=20 > protocol draft. > > That would work for me & Roberta. Is this OK to all? > > > Regarding Provisioning > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > We could move the definition of the Provisioning message into ancp-=20 > proto. ancp-mcast woudl then define the TLVs that are relevant for =20 > provisioning of multicast and that woudl be carried inside the =20 > Provisioning message defined in ancp-proto. > Note that there is currently no TLVs defined for teh provisioning of =20= > non-multicast things. So even if the Provisioning message is defined =20= > inside ancp-proto it wouldn't, for now, be of real use for ancp-=20 > proto. But still that seems like the right place to define the =20 > message itself. text for definition of Provisioning message in ancp-mcast will move to =20= ancp-proto. We'll make sure it is clear that Provisioning message is =20 not intended to superseed Port Management message (for per-line config). Please do let us know if you have comments/concerns with this proposal. Francois > Is this OK to all? > > Woj> Works for me. > > Regards, > Woj. > > Francois > > PS: in line with Woj suggestion, i sent an invite for editors of the =20= > two docs to discuss. > > On 11 Jun 2009, at 11:49, Maglione Roberta wrote: > >> Hi Woj, >> I=92m not sure I=92ve fully understood your proposal about =20 >> splitting the work between the two documents: >> > - ANCP base header definitions, extensions -> ancp-protocol >> =3D =3D> in my understanding this is the text from section 5.4.5, = isn=92t =20 >> it? >> However if we move the multicast messages and the error codes in =20 >> the other draft why should we leave in the base protocol the ANCP =20 >> base header definition? The ANCP message format defined in section =20= >> 5.4.5 is currently used only for Multicast messages (mcast =20 >> replication control message and mcast status message) thus if we =20 >> move these messages out of base protocol drafts shouldn=92t we move =20= >> also the ANCP base header specification? >> The only reason I thought about is because when we defined =20 >> multicast messages we introduced a new approach/logic for message =20 >> semantic: instead of re-using the same message for request and =20 >> response with different result code we used two different messages =20= >> for request and response and we added the result code =3D0 (ignore) =20= >> semantic. Is the specification of this behavior that you are =20 >> suggesting to keep in the base protocol draft in order to have this =20= >> approach available in future for other messages definitions? >> >- Mcast capability negotiation, messages, message flows, error =20 >> codes -> mcast ID >> Thanks, >> Regards >> Roberta >> From: BOCCI Matthew [mailto:Matthew.Bocci@alcatel-lucent.com] >> Sent: Tuesday, June 09, 2009 7:35 AM >> To: Wojciech Dec (wdec); Francois Le Faucheur (flefauch); Maglione =20= >> Roberta >> Cc: ancp@ietf.org >> Subject: RE: [ANCP] Splitting multicast from protocol doc >> I only actually saw one against for splitting the mcast text from =20 >> the ANCP protocol spec. However, I accept that it may not be that =20 >> easy to split it out. >> I am fine with the approach below, so long as the ANCP base =20 >> protocol spec can stand alone and that it is not necessary to =20 >> implement the mcast spec to support the base mcast functions in the =20= >> ANCP protocol spec. >> Matthew >> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >> Sent: 08 June 2009 12:19 >> To: Francois Le Faucheur (flefauch); BOCCI Matthew; Maglione Roberta >> Cc: ancp@ietf.org >> Subject: RE: [ANCP] Splitting multicast from protocol doc >> Hi Francois, >> let's go with the this approach. Some delicate surgery is needed on =20= >> the ancp-protocol draft to move the mcast specific parts to the new =20= >> ID, but leave the base protocol parts that have been defined (or re-=20= >> defined) as part of the mcast work in the base protocol spec. A =20 >> rough line to draw would be: >> - ANCP base header definitions, extensions -> ancp-protocol >> - Mcast capability negotiation, messages, message flows, error =20 >> codes -> mcast ID >> There are some provisioning aspects of the mcast use-cases (eg the =20= >> lists) that likely could apply to the wider provisioning use-case, =20= >> so this could go either way. >> It would seem like having the editors of both docs discuss the what =20= >> goes where would be a good next step. >> Regards, >> Woj. >> From: Francois Le Faucheur (flefauch) >> Sent: 08 June 2009 12:39 >> To: BOCCI Matthew; Wojciech Dec (wdec) >> Cc: ancp@ietf.org >> Subject: Re: [ANCP] Splitting multicast from protocol doc >> Matthew, Woj, >> We had a few responses to this proposal. What is the final decision? >> Thanks >> Francois >> On 31 Mar 2009, at 22:21, Francois Le Faucheur IMAP wrote: >> support. >> Francois >> On 31 Mar 2009, at 17:46, BOCCI Matthew wrote: >> There was a proposal at the last IETF to take the multicast text =20 >> from draft-ietf-ancp-protocol-05 and merge it with draft-lefaucheur-=20= >> ancp-mc-extensions-01. >> >> We would thus have two protocol drafts: >> >> draft-ietf-ancp-protocol : Containing the solutions for the =20 >> Topology discovery, line configuration and OAM use cases >> Multicast extensions draft: Containing the transactional multicast =20= >> solution and all of the content of draft-lefaucheur >> >> This would allow us to move forward with WG LC on the basic use =20 >> case solutions, and also keep all of the multicast extensions in a =20= >> single draft. >> >> Please can you indicate to the list whether you support this =20 >> proposal. >> >> Regards >> >> Matthew >> >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www.ietf.org/mailman/listinfo/ancp >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente =20= >> alle persone indicate. La diffusione, copia o qualsiasi altra =20 >> azione derivante dalla conoscenza di queste informazioni sono =20 >> rigorosamente vietate. Qualora abbiate ricevuto questo documento =20 >> per errore siete cortesemente pregati di darne immediata =20 >> comunicazione al mittente e di provvedere alla sua distruzione, =20 >> Grazie. >> This e-mail and any attachments is confidential and may contain =20 >> privileged information intended for the addressee(s) only. =20 >> Dissemination, copying, printing or use by anybody else is =20 >> unauthorised. If you are not the intended recipient, please delete =20= >> this message and any attachments and advise the sender by return e-=20= >> mail, Thanks. >> >> Rispetta l'ambiente. Non stampare questa =20= >> mail se non =E8 necessario. >> >> > --Apple-Mail-4-653248895 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable


Regarding the ANCP base = header:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
I think what Woj is proposing is = that:
* ancp-proto:
- keeps a small section that = introduce the notion that some ANCP message may be ANCP-specific = non-GSMP message = types
ancp-proto will include = a section on "generic ANCP protocol mechanisms for other uses cases". = This will discuss:
* alternate semantics for = Transaction ID (as used by macst use case)
* notion = of using different Message Types for a Response and the Request it is = responding to (as used by mcast use case)
* = Well-Known TLVs (Target, Command, = Status-Info)

ancp-mcast will refer to the = above section of ancp-proto when defining the mcast specific = messages/extensions.

text from current section = 5.4.5.2 and 5.4.5.3 (ie actual mcast messages) will move to = ancp-mcast.

text from current section 4.4 (ie = description of mcast use case) will move to ancp-mcast (and be expanded = to cover the other mcast use cases than transactional = mcast).

- defines the based header for = such messages (ie what is currently at the beginning of = 5.4.5 ) 
* ancp-multicast:
- refers to = ancp-proto for the definition of ANCP base header
- defines = multicats messages using this ANCP base header
Is that = right Woj? 
 
Woj> Yes, = that's it, noting that if people see a better way to cut-it-up, then = please do come forward with your opinions.
=
One other thing to  consider adding to the = ancp-multicast draft is of course the capability extension code = point(s), with the capability extension mechanism (negotiation?) = defined in the ancp-protocol draft.
 
That would work = for me & Roberta. Is this OK to all?

=

Regarding Provisioning
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
We = could move the definition of the Provisioning message into ancp-proto. = ancp-mcast woudl then define the TLVs that are relevant for provisioning = of multicast and that woudl be carried inside the Provisioning message = defined in ancp-proto.
Note that there is currently no = TLVs defined for teh provisioning of non-multicast things. So even if = the Provisioning message is defined inside ancp-proto it wouldn't, for = now, be of real use for ancp-proto. But still that seems = like the right place to define the message = itself.

text = for definition of Provisioning message in ancp-mcast will move to = ancp-proto. We'll make sure it is clear that Provisioning message is not = intended to superseed Port Management message (for per-line = config).

Please do let us know if you have = comments/concerns with this = proposal.

Francois

Is this OK to all? 
 
Woj> Works for me.
 
Regards,
Woj. 

=
Francois

PS: in line with Woj = suggestion, i sent an invite for editors of the two docs to = discuss.

On 11 Jun 2009, at 11:49, = Maglione Roberta wrote:

=
=
Hi Woj,
     I=92m not sure I=92ve fully = understood your proposal about splitting the work between the two = documents:
> - ANCP base header definitions, extensions -> = ancp-protocol
=3D =3D> in my understanding this is the text from section 5.4.5, isn=92t = it?
However if we move the multicast messages and the error codes = in the other draft why should we leave in the base protocol the ANCP = base header definition? The ANCP message format defined in section = 5.4.5 is currently used only for Multicast messages (mcast = replication control message and mcast status message) thus if we = move these messages out of base protocol drafts shouldn=92t we move also = the ANCP base header specification?
=
The only reason I thought about is because when we defined = multicast messages we introduced a new approach/logic for message = semantic: instead of re-using the same message for request and = response with different result code we used two different messages = for request and response and we added the result code =3D0 (ignore) = semantic. Is the specification of this behavior that you are = suggesting to keep in the base protocol draft in order to have this = approach available in future for other messages definitions? =  
>- Mcast capability = negotiation, messages, message flows, error codes -> mcast = ID
Thanks,
=
Regards
Roberta
From: BOCCI Matthew [mailto:Matthew.Bocci@alca= tel-lucent.com] 
Sent: Tuesday, June 09, 2009 7:35 = AM
To: Wojciech Dec (wdec); = Francois Le Faucheur (flefauch); Maglione Roberta
Cc: ancp@ietf.org
Subject: RE: [ANCP] Splitting = multicast from protocol doc
I only actually saw one against for = splitting the mcast text from the ANCP protocol spec. However, I = accept that it may not be that easy to split it = out.
I am fine with the approach below, so long as the ANCP base = protocol spec can stand alone and that it is not necessary to = implement the mcast spec to support the base mcast functions in the = ANCP protocol spec.
Matthew
=
=
From: Wojciech Dec = (wdec) [mailto:wdec@cisco.com] 
Sent: 08 June 2009 = 12:19
To: Francois Le Faucheur = (flefauch); BOCCI Matthew; Maglione Roberta
Cc: ancp@ietf.org
Subject: RE: [ANCP] Splitting = multicast from protocol doc
Hi = Francois,
=
let's go with the this = approach. Some delicate surgery is needed on the ancp-protocol draft = to move the mcast specific parts to the new ID, but leave the base = protocol parts that have been defined (or re-defined) as part = of the mcast work in the base protocol spec. A rough line to draw = would be:
=
- ANCP base header = definitions, extensions -> ancp-protocol
- Mcast capability negotiation, messages, = message flows, error codes -> mcast ID
There are some provisioning aspects of the mcast = use-cases (eg the lists) that likely could apply to the wider = provisioning use-case, so this could go either way.
It would seem like having = the editors of both docs discuss the what goes where would be a = good next step.
Regards,
=
Woj.
=
=
From: Francois Le = Faucheur (flefauch) 
Sent: 08 June 2009 = 12:39
To: BOCCI Matthew; Wojciech Dec = (wdec)
Cc: ancp@ietf.org
Subject: Re: [ANCP] Splitting = multicast from protocol doc
Matthew, Woj,
=
We had a few responses to this proposal. = What is the final decision?
=
Thanks
=
Francois
=
On 31 Mar 2009, at 22:21, Francois Le = Faucheur IMAP wrote:
=
support.
Francois
=
On 31 Mar 2009, at 17:46, BOCCI Matthew wrote:

There was a proposal at = the last IETF to take the multicast text from = draft-ietf-ancp-protocol-05 and merge it with = draft-lefaucheur-ancp-mc-extensions-01.

We would thus have two = protocol drafts:

draft-ietf-ancp-protocol : = Containing the solutions for the Topology discovery, line = configuration and OAM use cases 
Multicast extensions draft: Containing the = transactional multicast solution and all of the content of = draft-lefaucheur

This would allow us to = move forward with WG LC on the basic use case solutions, and also = keep all of the multicast extensions in a single = draft.

Please can = you indicate to the list whether you support this = proposal.

Regards

Matthew

=
_______________________________________________
ANCP = mailing list
ANCP@ietf.org
https://www.ietf.org/m= ailman/listinfo/ancp
=
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.

<logo = Ambiente_foglia.jpg>Rispetta l'ambiente. Non stampare questa = mail se non =E8 necessario.

&= lt;logo = Ambiente_foglia.jpg>


= --Apple-Mail-4-653248895-- From Sidd.Aanand@ecitele.com Tue Jun 23 07:06:02 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BE9D3A6CDF for ; Tue, 23 Jun 2009 07:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ky9uRozUEjTU for ; Tue, 23 Jun 2009 07:06:01 -0700 (PDT) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id 24F3A3A6BE9 for ; Tue, 23 Jun 2009 07:06:00 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by ilptiron01.ecitele.com with ESMTP; 23 Jun 2009 17:01:55 +0300 Received: from ilptexch01.ecitele.com ([172.31.244.40]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Jun 2009 17:06:16 +0300 Received: from ilptextms01.ecitele.com (147.234.245.175) by ilptexch01.ecitele.com (172.31.244.40) with Microsoft SMTP Server id 8.1.375.2; Tue, 23 Jun 2009 17:06:16 +0300 Received: from USPITMAIL02.ecitele.com ([10.0.0.30]) by ilptextms01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Jun 2009 17:06:15 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F40B.C2A59BCE" Date: Tue, 23 Jun 2009 10:06:10 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Topology discovery question Thread-Index: Acn0C8KG7qBrFyurRJSNtwJlC9T6ng== From: Sidd Aanand To: X-OriginalArrivalTime: 23 Jun 2009 14:06:15.0766 (UTC) FILETIME=[C5D50760:01C9F40B] Cc: "Keith A. Monahan" , Mark Dyga Subject: [ANCP] Topology discovery question X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 14:06:02 -0000 ------_=_NextPart_001_01C9F40B.C2A59BCE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 Section 5.4.2 of the v05 ANCP draft says: Also, when the ANCP session first comes up, the DSLAM SHOULD transmit=20 a PORT UP message to the NAS for each line that is up.=20 Is the expectation that each PORT UP message is sent as a separate GSMP message or is the DSLAM expected to batch a set of PORT UP messages in a single GSMP message? If it is the latter, how does the message convey how many port up messages are contained within the single GSMP message? =20 Thanks, Sidd ------_=_NextPart_001_01C9F40B.C2A59BCE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
Section 5.4.2 of the=20 v05 ANCP draft says:
Also, when the ANCP =
session first comes up, the DSLAM SHOULD transmit 
a PORT UP message to the NAS for each line that is =
up.
Is the = expectation=20 that each PORT UP message is sent as a separate GSMP message or is the = DSLAM=20 expected to batch a set of PORT UP messages in a single GSMP message? If = it is=20 the latter, how does the message convey how many port up messages are = contained=20 within the single GSMP message?
 
Thanks,
Sidd
------_=_NextPart_001_01C9F40B.C2A59BCE-- From flefauch@cisco.com Tue Jun 23 08:49:20 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069DE28C373 for ; Tue, 23 Jun 2009 08:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.474 X-Spam-Level: X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjx+vGvq53gI for ; Tue, 23 Jun 2009 08:49:17 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0A1A028C343 for ; Tue, 23 Jun 2009 08:49:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,276,1243814400"; d="scan'208,217";a="43486073" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 23 Jun 2009 15:49:31 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5NFnVSl014954; Tue, 23 Jun 2009 17:49:31 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5NFnVfr011005; Tue, 23 Jun 2009 15:49:31 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jun 2009 17:49:30 +0200 Received: from ams-flefauch-8712.cisco.com ([10.55.161.195]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jun 2009 17:49:28 +0200 Message-Id: <71304EF1-AAAA-4425-8096-0FC16CF39E8C@cisco.com> From: Francois Le Faucheur IMAP To: Maglione Roberta , Sanjay Wadhwa In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-18--970489143 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 23 Jun 2009 17:49:26 +0200 References: <0458D2EE0C36744BABB36BE37805C29A039300AF@FRVELSMBS11.ad2.ad.alcatel.com> <671A5BF3-6386-4741-84C2-5B3051D77DAA@cisco.com> <0458D2EE0C36744BABB36BE37805C29A03EC4066@FRVELSMBS11.ad2.ad.alcatel.com> <282BBE8A501E1F4DA9C775F964BB21FE3E60EF3566@GRFMBX704BA020.griffon.local> <5DAF167E-64F2-4CD6-A230-709B0920CC1C@cisco.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 23 Jun 2009 15:49:28.0733 (UTC) FILETIME=[3120CCD0:01C9F41A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=48958; t=1245772171; x=1246636171; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Status-Info=20Result=20Code=20Registry=20=20Re= 3A=20[ANCP]=20Splitting=20multicast=20from=20protocol=20doc |Sender:=20; bh=pUceLTCi7ppxNYdhwtBktcmvp1bbyF6o6m7YcKFk0jU=; b=BXRfaJbHO8XFWOCN21+aX9iD+YpF8JKP/f3NX5YdMtXB9270Pa4aaKEoLp yk0y/ZHVwBWeginJ14JdTOBKefkxgKyNCCwzF5TIIw4c+uAldNhiINcK74XR 9gmkRAtS4Z; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ancp@ietf.org Subject: [ANCP] Status-Info Result Code Registry Re: Splitting multicast from protocol doc X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 15:49:20 -0000 --Apple-Mail-18--970489143 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Roberta, Sanjay, We agreed that : (i) the Well-Known TLV specification (eg equivalent of 5.4.5.1.3 = of =20 ancp-proto) would remain in ancp-proto (as a Well-Known TLV) (ii) the use and encoding of theses TLV by Multicast messages = (eg =20 equivalent of 5.4.5.3 in ancp-proto) would go into the multicast I-D. Now, the Well-Known TLVs seem to have an encoding that depends on the =20= actual ANCP message using the TLV. For example, for the Status TLV, ancp-proto says: " Result Code: Conveys the result code for the command or message, as defined by the application. " Similarly, for the Command TLV, ancp-proto says: " Command-Info: Command information as defined for each message type. The field can consist of sub-TLVs. " My assumption is that: * there is a single shared registry for "Result Codes" for the Status-=20= Info TLV (which will contain the reunion of all the values defined by =20= the multiple message types that can use the TLV). * there is a single shared registry for "Command Code" of the Command =20= TLV (which will contain the reunion of all the values defined by the =20 multiple message types that can use the TLV). Therefore, I assume that : * ancp-proto will define (in IANA section) the single Result = Code =20 registry for Status-Info TLV but will not allocate values * multicast I-D will allocate Result Code values * ancp-proto will define (in IANA section) the single Command = Code =20 registry for Command TLV but will not allocate values * multicast I-D will allocate Command Code values Please let me know if this is not the right approach. Thanks Francois On 17 Jun 2009, at 16:20, Francois Le Faucheur IMAP wrote: > Folks, > > Sanjay, Roberta and I had a first chat. Our proposal is in line with =20= > the thread below with a few more specifics described below: > >> >> >> Regarding the ANCP base header: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >> I think what Woj is proposing is that: >> * ancp-proto: >> - keeps a small section that introduce the notion that some ANCP =20 >> message may be ANCP-specific non-GSMP message types > ancp-proto will include a section on "generic ANCP protocol =20 > mechanisms for other uses cases". This will discuss: > * alternate semantics for Transaction ID (as used by macst use = case) > * notion of using different Message Types for a Response and the = =20 > Request it is responding to (as used by mcast use case) > * Well-Known TLVs (Target, Command, Status-Info) > > ancp-mcast will refer to the above section of ancp-proto when =20 > defining the mcast specific messages/extensions. > > text from current section 5.4.5.2 and 5.4.5.3 (ie actual mcast =20 > messages) will move to ancp-mcast. > > text from current section 4.4 (ie description of mcast use case) =20 > will move to ancp-mcast (and be expanded to cover the other mcast =20 > use cases than transactional mcast). >> >> - defines the based header for such messages (ie what is currently =20= >> at the beginning of 5.4.5 ) >> * ancp-multicast: >> - refers to ancp-proto for the definition of ANCP base header >> - defines multicats messages using this ANCP base header >> Is that right Woj? >> >> Woj> Yes, that's it, noting that if people see a better way to cut-=20= >> it-up, then please do come forward with your opinions. >> One other thing to consider adding to the ancp-multicast draft is =20= >> of course the capability extension code point(s), with the =20 >> capability extension mechanism (negotiation?) defined in the ancp-=20 >> protocol draft. >> >> That would work for me & Roberta. Is this OK to all? >> >> >> Regarding Provisioning >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> We could move the definition of the Provisioning message into ancp-=20= >> proto. ancp-mcast woudl then define the TLVs that are relevant for =20= >> provisioning of multicast and that woudl be carried inside the =20 >> Provisioning message defined in ancp-proto. >> Note that there is currently no TLVs defined for teh provisioning =20 >> of non-multicast things. So even if the Provisioning message is =20 >> defined inside ancp-proto it wouldn't, for now, be of real use for =20= >> ancp-proto. But still that seems like the right place to define the =20= >> message itself. > > text for definition of Provisioning message in ancp-mcast will move =20= > to ancp-proto. We'll make sure it is clear that Provisioning message =20= > is not intended to superseed Port Management message (for per-line =20 > config). > > Please do let us know if you have comments/concerns with this =20 > proposal. > > Francois > >> Is this OK to all? >> >> Woj> Works for me. >> >> Regards, >> Woj. >> >> Francois >> >> PS: in line with Woj suggestion, i sent an invite for editors of =20 >> the two docs to discuss. >> >> On 11 Jun 2009, at 11:49, Maglione Roberta wrote: >> >>> Hi Woj, >>> I=92m not sure I=92ve fully understood your proposal about =20 >>> splitting the work between the two documents: >>> > - ANCP base header definitions, extensions -> ancp-protocol >>> =3D =3D> in my understanding this is the text from section 5.4.5, =20= >>> isn=92t it? >>> However if we move the multicast messages and the error codes in =20 >>> the other draft why should we leave in the base protocol the ANCP =20= >>> base header definition? The ANCP message format defined in section =20= >>> 5.4.5 is currently used only for Multicast messages (mcast =20 >>> replication control message and mcast status message) thus if we =20 >>> move these messages out of base protocol drafts shouldn=92t we move =20= >>> also the ANCP base header specification? >>> The only reason I thought about is because when we defined =20 >>> multicast messages we introduced a new approach/logic for message =20= >>> semantic: instead of re-using the same message for request and =20 >>> response with different result code we used two different messages =20= >>> for request and response and we added the result code =3D0 (ignore) =20= >>> semantic. Is the specification of this behavior that you are =20 >>> suggesting to keep in the base protocol draft in order to have =20 >>> this approach available in future for other messages definitions? >>> >- Mcast capability negotiation, messages, message flows, error =20 >>> codes -> mcast ID >>> Thanks, >>> Regards >>> Roberta >>> From: BOCCI Matthew [mailto:Matthew.Bocci@alcatel-lucent.com] >>> Sent: Tuesday, June 09, 2009 7:35 AM >>> To: Wojciech Dec (wdec); Francois Le Faucheur (flefauch); Maglione =20= >>> Roberta >>> Cc: ancp@ietf.org >>> Subject: RE: [ANCP] Splitting multicast from protocol doc >>> I only actually saw one against for splitting the mcast text from =20= >>> the ANCP protocol spec. However, I accept that it may not be that =20= >>> easy to split it out. >>> I am fine with the approach below, so long as the ANCP base =20 >>> protocol spec can stand alone and that it is not necessary to =20 >>> implement the mcast spec to support the base mcast functions in =20 >>> the ANCP protocol spec. >>> Matthew >>> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >>> Sent: 08 June 2009 12:19 >>> To: Francois Le Faucheur (flefauch); BOCCI Matthew; Maglione Roberta >>> Cc: ancp@ietf.org >>> Subject: RE: [ANCP] Splitting multicast from protocol doc >>> Hi Francois, >>> let's go with the this approach. Some delicate surgery is needed =20 >>> on the ancp-protocol draft to move the mcast specific parts to the =20= >>> new ID, but leave the base protocol parts that have been defined =20 >>> (or re-defined) as part of the mcast work in the base protocol =20 >>> spec. A rough line to draw would be: >>> - ANCP base header definitions, extensions -> ancp-protocol >>> - Mcast capability negotiation, messages, message flows, error =20 >>> codes -> mcast ID >>> There are some provisioning aspects of the mcast use-cases (eg the =20= >>> lists) that likely could apply to the wider provisioning use-case, =20= >>> so this could go either way. >>> It would seem like having the editors of both docs discuss the =20 >>> what goes where would be a good next step. >>> Regards, >>> Woj. >>> From: Francois Le Faucheur (flefauch) >>> Sent: 08 June 2009 12:39 >>> To: BOCCI Matthew; Wojciech Dec (wdec) >>> Cc: ancp@ietf.org >>> Subject: Re: [ANCP] Splitting multicast from protocol doc >>> Matthew, Woj, >>> We had a few responses to this proposal. What is the final decision? >>> Thanks >>> Francois >>> On 31 Mar 2009, at 22:21, Francois Le Faucheur IMAP wrote: >>> support. >>> Francois >>> On 31 Mar 2009, at 17:46, BOCCI Matthew wrote: >>> There was a proposal at the last IETF to take the multicast text =20 >>> from draft-ietf-ancp-protocol-05 and merge it with draft-=20 >>> lefaucheur-ancp-mc-extensions-01. >>> >>> We would thus have two protocol drafts: >>> >>> draft-ietf-ancp-protocol : Containing the solutions for the =20 >>> Topology discovery, line configuration and OAM use cases >>> Multicast extensions draft: Containing the transactional multicast =20= >>> solution and all of the content of draft-lefaucheur >>> >>> This would allow us to move forward with WG LC on the basic use =20 >>> case solutions, and also keep all of the multicast extensions in a =20= >>> single draft. >>> >>> Please can you indicate to the list whether you support this =20 >>> proposal. >>> >>> Regards >>> >>> Matthew >>> >>> _______________________________________________ >>> ANCP mailing list >>> ANCP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ancp >>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente =20= >>> alle persone indicate. La diffusione, copia o qualsiasi altra =20 >>> azione derivante dalla conoscenza di queste informazioni sono =20 >>> rigorosamente vietate. Qualora abbiate ricevuto questo documento =20 >>> per errore siete cortesemente pregati di darne immediata =20 >>> comunicazione al mittente e di provvedere alla sua distruzione, =20 >>> Grazie. >>> This e-mail and any attachments is confidential and may contain =20 >>> privileged information intended for the addressee(s) only. =20 >>> Dissemination, copying, printing or use by anybody else is =20 >>> unauthorised. If you are not the intended recipient, please delete =20= >>> this message and any attachments and advise the sender by return e-=20= >>> mail, Thanks. >>> >>> Rispetta l'ambiente. Non stampare questa =20= >>> mail se non =E8 necessario. >>> >>> >> > --Apple-Mail-18--970489143 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
Roberta, = Sanjay,

We agreed that :
= (i) the Well-Known TLV specification (eg equivalent of = 5.4.5.1.3 of ancp-proto) would remain in ancp-proto (as a Well-Known = TLV)
= (ii) the use and encoding of theses TLV by Multicast messages (eg = equivalent of 5.4.5.3 in ancp-proto) would go into the multicast = I-D. 

Now, the Well-Known TLVs seem to = have an encoding that depends on the actual ANCP message using the = TLV. 
For example, for the Status TLV, ancp-proto = says:
"   Result Code:
     =         Conveys the result code for the command or = message, as
             = defined by the application.
"
Similarly, for the = Command TLV, ancp-proto says:
"   = Command-Info:
             = Command information as defined for each message type. =  The
             = field can consist of sub-TLVs.
"

My = assumption is that:
* there is a single shared registry = for "Result Codes" for the Status-Info TLV (which will = contain the reunion of all the values defined = by the multiple message types that can use the = TLV). 
* there is a single shared registry for = "Command Code"  of the Command TLV (which will = contain the reunion of all the values defined = by the multiple message types that can use the = TLV). 

Therefore, I assume that = :
= * ancp-proto will define (in IANA section) the = single Result Code registry for Status-Info TLV but will not allocate = values
* multicast I-D will = allocate Result Code values
= * ancp-proto will define (in IANA section) the = single Command Code registry for Command TLV but will not allocate = values
* multicast I-D will allocate = Command Code values

Please let me know if = this is not the right = approach.


Thanks
<= br>
Francois



<= br>
On 17 Jun 2009, at 16:20, Francois Le Faucheur IMAP = wrote:



Regarding the ANCP base = header:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
I think what Woj is proposing is = that:
* ancp-proto:
- keeps a small section that = introduce the notion that some ANCP message may be ANCP-specific = non-GSMP message = types
ancp-proto will include = a section on "generic ANCP protocol mechanisms for other uses cases". = This will discuss:
* alternate semantics for = Transaction ID (as used by macst use case)
* notion = of using different Message Types for a Response and the Request it is = responding to (as used by mcast use case)
* = Well-Known TLVs (Target, Command, = Status-Info)

ancp-mcast will refer to the = above section of ancp-proto when defining the mcast specific = messages/extensions.

text from current section = 5.4.5.2 and 5.4.5.3 (ie actual mcast messages) will move to = ancp-mcast.

text from current section 4.4 (ie = description of mcast use case) will move to ancp-mcast (and be expanded = to cover the other mcast use cases than transactional = mcast).

- defines the based header for = such messages (ie what is currently at the beginning of = 5.4.5 ) 
* ancp-multicast:
- refers to = ancp-proto for the definition of ANCP base header
- defines = multicats messages using this ANCP base header
Is that = right Woj? 
 
Woj> Yes, = that's it, noting that if people see a better way to cut-it-up, then = please do come forward with your opinions.
=
One other thing to  consider adding to the = ancp-multicast draft is of course the capability extension code = point(s), with the capability extension mechanism (negotiation?) = defined in the ancp-protocol draft.
 
That would work = for me & Roberta. Is this OK to all?

=

Regarding Provisioning
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
We = could move the definition of the Provisioning message into ancp-proto. = ancp-mcast woudl then define the TLVs that are relevant for provisioning = of multicast and that woudl be carried inside the Provisioning message = defined in ancp-proto.
Note that there is currently no = TLVs defined for teh provisioning of non-multicast things. So even if = the Provisioning message is defined inside ancp-proto it wouldn't, for = now, be of real use for ancp-proto. But still that seems = like the right place to define the message = itself.

text = for definition of Provisioning message in ancp-mcast will move to = ancp-proto. We'll make sure it is clear that Provisioning message is not = intended to superseed Port Management message (for per-line = config).

Please do let us know if you have = comments/concerns with this = proposal.

Francois

Is this OK to all? 
 
Woj> Works for me.
 
Regards,
Woj. 

=
Francois

PS: in line with Woj = suggestion, i sent an invite for editors of the two docs to = discuss.

On 11 Jun 2009, at 11:49, = Maglione Roberta wrote:

=
=
Hi Woj,
     I=92m not sure I=92ve fully = understood your proposal about splitting the work between the two = documents:
> - ANCP base header definitions, extensions -> = ancp-protocol
=3D =3D> in my understanding this is the text from section 5.4.5, isn=92t = it?
However if we move the multicast messages and the error codes = in the other draft why should we leave in the base protocol the ANCP = base header definition? The ANCP message format defined in section = 5.4.5 is currently used only for Multicast messages (mcast = replication control message and mcast status message) thus if we = move these messages out of base protocol drafts shouldn=92t we move also = the ANCP base header specification?
=
The only reason I thought about is because when we defined = multicast messages we introduced a new approach/logic for message = semantic: instead of re-using the same message for request and = response with different result code we used two different messages = for request and response and we added the result code =3D0 (ignore) = semantic. Is the specification of this behavior that you are = suggesting to keep in the base protocol draft in order to have this = approach available in future for other messages definitions? =  
>- Mcast capability = negotiation, messages, message flows, error codes -> mcast = ID
Thanks,
=
Regards
Roberta
From: BOCCI Matthew [mailto:Matthew.Bocci@alca= tel-lucent.com] 
Sent: Tuesday, June 09, 2009 7:35 = AM
To: Wojciech Dec (wdec); = Francois Le Faucheur (flefauch); Maglione Roberta
Cc: ancp@ietf.org
Subject: RE: [ANCP] Splitting = multicast from protocol doc
I only actually saw one against for = splitting the mcast text from the ANCP protocol spec. However, I = accept that it may not be that easy to split it = out.
I am fine with the approach below, so long as the ANCP base = protocol spec can stand alone and that it is not necessary to = implement the mcast spec to support the base mcast functions in the = ANCP protocol spec.
Matthew
=
=
From: Wojciech Dec = (wdec) [mailto:wdec@cisco.com] 
Sent: 08 June 2009 = 12:19
To: Francois Le Faucheur = (flefauch); BOCCI Matthew; Maglione Roberta
Cc: ancp@ietf.org
Subject: RE: [ANCP] Splitting = multicast from protocol doc
Hi = Francois,
=
let's go with the this = approach. Some delicate surgery is needed on the ancp-protocol draft = to move the mcast specific parts to the new ID, but leave the base = protocol parts that have been defined (or re-defined) as part = of the mcast work in the base protocol spec. A rough line to draw = would be:
=
- ANCP base header = definitions, extensions -> ancp-protocol
- Mcast capability negotiation, messages, = message flows, error codes -> mcast ID
There are some provisioning aspects of the mcast = use-cases (eg the lists) that likely could apply to the wider = provisioning use-case, so this could go either way.
It would seem like having = the editors of both docs discuss the what goes where would be a = good next step.
Regards,
=
Woj.
=
=
From: Francois Le = Faucheur (flefauch) 
Sent: 08 June 2009 = 12:39
To: BOCCI Matthew; Wojciech Dec = (wdec)
Cc: ancp@ietf.org
Subject: Re: [ANCP] Splitting = multicast from protocol doc
Matthew, Woj,
=
We had a few responses to this proposal. = What is the final decision?
=
Thanks
=
Francois
=
On 31 Mar 2009, at 22:21, Francois Le = Faucheur IMAP wrote:
=
support.
Francois
=
On 31 Mar 2009, at 17:46, BOCCI Matthew wrote:

There was a proposal at = the last IETF to take the multicast text from = draft-ietf-ancp-protocol-05 and merge it with = draft-lefaucheur-ancp-mc-extensions-01.

We would thus have two = protocol drafts:

draft-ietf-ancp-protocol : = Containing the solutions for the Topology discovery, line = configuration and OAM use cases 
Multicast extensions draft: Containing the = transactional multicast solution and all of the content of = draft-lefaucheur

This would allow us to = move forward with WG LC on the basic use case solutions, and also = keep all of the multicast extensions in a single = draft.

Please can = you indicate to the list whether you support this = proposal.

Regards

Matthew

=
_______________________________________________
ANCP = mailing list
ANCP@ietf.org
https://www.ietf.org/m= ailman/listinfo/ancp
=
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.

<logo = Ambiente_foglia.jpg>Rispetta l'ambiente. Non stampare questa = mail se non =E8 necessario.

&= lt;logo = Ambiente_foglia.jpg>



= --Apple-Mail-18--970489143-- From wdec@cisco.com Wed Jun 24 05:46:15 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8498F28C4A1 for ; Wed, 24 Jun 2009 05:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.323 X-Spam-Level: X-Spam-Status: No, score=-7.323 tagged_above=-999 required=5 tests=[AWL=-0.725, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EifkbwaJSGP1 for ; Wed, 24 Jun 2009 05:46:14 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7D21E28C475 for ; Wed, 24 Jun 2009 05:46:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,283,1243814400"; d="scan'208,217";a="179845794" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-2.cisco.com with ESMTP; 24 Jun 2009 12:42:57 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5OCgtrR011137; Wed, 24 Jun 2009 14:42:55 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5OCgtoB015962; Wed, 24 Jun 2009 12:42:55 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jun 2009 14:42:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F4C9.4BD26B87" Date: Wed, 24 Jun 2009 14:42:50 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Topology discovery question Thread-Index: Acn0C8KG7qBrFyurRJSNtwJlC9T6ngAvTb1g References: From: "Wojciech Dec (wdec)" To: "Sidd Aanand" , X-OriginalArrivalTime: 24 Jun 2009 12:42:55.0685 (UTC) FILETIME=[4BF6F750:01C9F4C9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4345; t=1245847375; x=1246711375; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20Topology=20discovery=20questio n |Sender:=20; bh=koeB4lkxvajKTI1p9KVzdRHrSmPsSYl+pJj6ZZZbYUs=; b=Wi3jUePkoXCx9zGYNXPVTDcx+cgdXXpU+3915oJ4XIGVFld8WKr7FmIa9u kuTzzt4Tdcgq/mdJ3XeTwEHIGr0N2awJ16SD/lw8ClIbSYFiHm9HlyeuDD4k iURG6hUJet; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "Keith A. Monahan" , Mark Dyga Subject: Re: [ANCP] Topology discovery question X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 12:46:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9F4C9.4BD26B87 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 well, each Port-up should be sent in a separate message, however note that since ANCP runs on TCP this doesn't actually matter much. =20 Cheers, Woj. ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Sidd Aanand Sent: 23 June 2009 16:06 To: ancp@ietf.org Cc: Keith A. Monahan; Mark Dyga Subject: [ANCP] Topology discovery question =09 =09 Hi All, =20 Section 5.4.2 of the v05 ANCP draft says: =09 Also, when the ANCP session first comes up, the DSLAM SHOULD transmit=20 a PORT UP message to the NAS for each line that is up.=20 Is the expectation that each PORT UP message is sent as a separate GSMP message or is the DSLAM expected to batch a set of PORT UP messages in a single GSMP message? If it is the latter, how does the message convey how many port up messages are contained within the single GSMP message? =20 Thanks, Sidd ------_=_NextPart_001_01C9F4C9.4BD26B87 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
well, each Port-up should be sent in a separate message, = however note=20 that since ANCP runs on TCP this doesn't actually matter=20 much.
 
Cheers,
Woj.

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Sidd = Aanand
Sent:=20 23 June 2009 16:06
To: ancp@ietf.org
Cc: Keith A. = Monahan;=20 Mark Dyga
Subject: [ANCP] Topology discovery=20 question

Hi=20 All,
 
Section 5.4.2 of=20 the v05 ANCP draft says:
Also, when the ANCP =
session first comes up, the DSLAM SHOULD transmit 
a PORT UP message to the NAS for each line that is =
up.
Is = the expectation=20 that each PORT UP message is sent as a separate GSMP message or is the = DSLAM=20 expected to batch a set of PORT UP messages in a single GSMP message? = If it is=20 the latter, how does the message convey how many port up messages are=20 contained within the single GSMP message?
 
Thanks,
Sidd
------_=_NextPart_001_01C9F4C9.4BD26B87-- From flefauch@cisco.com Wed Jun 24 06:22:09 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89D2428C4A7 for ; Wed, 24 Jun 2009 06:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.255 X-Spam-Level: X-Spam-Status: No, score=-10.255 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZLHIuBS9ejG for ; Wed, 24 Jun 2009 06:22:07 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 4C72228C39B for ; Wed, 24 Jun 2009 06:22:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,283,1243814400"; d="scan'208,217";a="43559999" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 24 Jun 2009 13:20:57 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5ODKv1w024463; Wed, 24 Jun 2009 15:20:57 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5ODKvZt000816; Wed, 24 Jun 2009 13:20:57 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jun 2009 15:20:57 +0200 Received: from ams-flefauch-8712.cisco.com ([10.55.161.195]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jun 2009 15:20:54 +0200 Message-Id: From: Francois Le Faucheur IMAP To: ancp@ietf.org, "Aniruddha (anira) A" Content-Type: multipart/alternative; boundary=Apple-Mail-34--893003094 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 24 Jun 2009 15:20:52 +0200 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 24 Jun 2009 13:20:54.0863 (UTC) FILETIME=[9A75EDF0:01C9F4CE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=58717; t=1245849657; x=1246713657; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Fwd=3A=20ANCP=20Multicast=20I-D=20Changes |Sender:=20; bh=XzWeGdWoXKqJVsDcsvvzvqhDiSvPuBt/qPU7ZrZp0u8=; b=KDBxRbLmDiQo3JMYb7nVYd7tg9w6wPlCdyCKH1eJUqTK0y7cJeTxFQtLaz v/xhEdZ/aF3BplYmaSGOzYvRW5oXRz1CEaoqt7Lv4Tj9ql87t1m7TSOp8Qcw BbshrzO0kQ; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [ANCP] Fwd: ANCP Multicast I-D Changes X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 13:22:09 -0000 --Apple-Mail-34--893003094 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Folks, I am drafting text to incorporate something based on the proposal below to support query by NAS about active multicast flows on AN. Now would be a good time to provide comments on this topic if you have any. I will propose using Message-Type 0x97 (since the earlier number are now allocated) Aniruddha, I don't quite see the role of the "Active-Flow-Req TLV" since it is always present in all "Request" messages from NAS and doe snot convey actual information. I am guessing this may have been included to distinguish the Request from the Response, but I think this can be easily inferred by the direction NAS-->AN vs AN-->NAS. Somewhat similar to what is already done for the Delegated Bandwidth Query Request/Response of ancp-mc-extensions-01. Is this TLV really needed? Thanks Francois > > > Begin forwarded message: > >> From: "BOCCI Matthew" >> Date: 31 March 2009 17:51:37 CEDT >> To: "Aniruddha A (anira)" , >> Subject: Re: [ANCP] ANCP messages for Multicast query and report >> >> This was discussed in San Francisco, and there seemed to be >> agreement in >> principle, but we would appreciate feedback on this proposal on the >> list >> from the WG. >> >> Matthew >> >> >>> -----Original Message----- >>> From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On >>> Behalf Of Aniruddha A (anira) >>> Sent: 06 March 2009 11:00 >>> To: ancp@ietf.org >>> Subject: Re: [ANCP] ANCP messages for Multicast query and report >>> >>> >>> >>> Hi All, >>> >>> I propose the following new ANCP message to get all ports on >>> AN for a given Multicast flow (S,G) : >>> >>> - Request message from NAS to AN to get all the ports where a >>> multicast >>> flow is active. >>> The Mandatory Active-Flow-Req TLV is followed by the Flow-ID TLV >>> which identifies which flow we are interested in. >>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Type (0x88-0C) | >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Vers | Sub |MsgType=0x92 | Res | >>> Code | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Partition ID | Transaction >>> Identifier | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> |I| SubMessage Number | >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | ActiveFlowReq TLV =0x103 | ActiveFlow- >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Mcast Flow ID TLV = 0x107 |S| Mcast Flow ID- >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | AddrFamily | EncType | Mcast >>> source | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | AddrFamily | EncType | Mcast >>> group | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> >>> - Report message from AN to NAS to send all the ports for a >>> particular flow. >>> The report uses a new TLV - 0x108 >>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Type (0x88-0C) | >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Vers | Sub |MsgType=0x92 | Res | >>> Code | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Partition ID | Transaction >>> Identifier | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> |I| SubMessage Number | >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> |ActiveFlow Target Ports = 0x108| ActiveFlow- >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Mcast Flow ID TLV = 0x107 |S| Mcast Flow ID- >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | AddrFamily | EncType | Mcast >>> source | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | AddrFamily | EncType | Mcast >>> group | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> >>> Followed by one or more Target-Type TLV which identifies the port >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Target-type-TLV=0x1000 | Target-TLV- >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | ID type | Circuit ID >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> >>> | | >>> ~ Client- >>> ID ~ >>> >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> >>> >>> -- >>> Regards, >>> Aniruddha. A >>> >>> -----Original Message----- >>> From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] >>> Sent: Thursday, February 05, 2009 9:19 PM >>> To: Aniruddha A (anira); ancp@ietf.org >>> Subject: RE: ANCP messages for Multicast query and report >>> >>> Hi Aniruddha, >>> your proposal seems interesting to me, but I have a comment: >>> section 3.4.3 of the ancp-framework draft defines 3 different >>> types of reporting function: >>> - report for one Access Port; >>> - report for one multicast flow; >>> - a global report for one Access Node. >>> >>> If my understanding is correct, your proposal addresses 1 and >>> 3, do you plan to extend it to cover also case 2? >>> >>> Thanks and best regards. >>> Roberta >>> >>> -----Original Message----- >>> From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On >>> Behalf Of Aniruddha A (anira) >>> Sent: Monday, January 12, 2009 6:46 PM >>> To: ancp@ietf.org >>> Subject: [ANCP] ANCP messages for Multicast query and report >>> >>> Hi all, >>> >>> In the ANCP multicast extensions, there has to be a way For >>> the NAS to query the AN for the state of active multicast flows on >>> it. >>> >>> We propose the following 2 new messages for this purpose: >>> - Active-Flow Request >>> - Active-Flow Report >>> >>> The query from the NAS can be for all flows on the AN or >>> flows active on a single port. Message Type 0x92 is used. >>> >>> Description and message formats: >>> >>> Active-Flow Request Message >>> >>> The Active Flow Request message is sent by the NAS to the AN to >>> request multicast flow status on the AN. The payload contains the >>> following TLVs: >>> >>> o The Active-Flow-Req TLV (0x103) >>> A Mandatory TLV. >>> >>> o The Target Type TLV. >>> Optional TLV, if present, request is for a single port. >>> >>> On receiving the Active Flow Request message, the AN MUST respond >>> with the Active Flow Report containing the requested information >>> if >>> the Multicast capability has been negotiated. The format of the >>> message is shown below: >>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Type (0x88-0C) | >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Vers | Sub |MsgType=0x92 | Res | >>> Code | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Partition ID | Transaction >>> Identifier | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> |I| SubMessage Number | >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | ActiveFlowReq TLV =0x103 | ActiveFlow- >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Target-type-TLV=0x1000 | Target-TLV- >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | ID type | Circuit ID >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> >>> | | >>> ~ Client- >>> ID ~ >>> >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> >>> Figure 1 >>> >>> Active-Flow Report Message >>> >>> The Active Flow Report message is sent from the AN to the NAS in >>> response to the Active Flow Request message. Active Flow Report >>> message contains information on the requested multicast flows. >>> The >>> report can be for a single port, or all ports depending on >>> the Target >>> Type in the request. >>> >>> o Single Port Report >>> >>> If the Active Flow Request had a specific port (the presence of a >>> Target Type TLV), the response has the following format: >>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Type (0x88-0C) | >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Vers | Sub |MsgType=0x92 | Res | >>> Code | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Partition ID | Transaction >>> Identifier | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> |I| SubMessage Number | >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | ActiveFlowPortEntryTLV =0x105 | ActiveFlow- >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Target-type-TLV=0x1000 | Target-TLV- >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | ID type | Circuit ID >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> >>> | | >>> ~ Client- >>> ID ~ >>> >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> >>> Figure 2 >>> >>> Followed by the Multicast Flow ID TLVs (0x107), one for >>> each flow on >>> the port. The format of the Flow ID TLV is: >>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Mcast Flow ID TLV = 0x107 |S| Mcast Flow ID- >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | AddrFamily | EncType | Mcast >>> source | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | AddrFamily | EncType | Mcast >>> group | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> >>> Figure 3 >>> >>> S is the source flag, if set, multicast source address MUST be >>> present (SSM). >>> >>> o Report for all ports >>> >>> If the Active Flow Request did not specify a specific port >>> (no Target >>> Type TLV), the response will have the following format: >>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Type (0x88-0C) | >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Vers | Sub |MsgType=0x92 | Res | >>> Code | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Partition ID | Transaction >>> Identifier | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> |I| SubMessage Number | >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> |ActiveFlowMcastEntryTLV =0x104 | ActiveFlow- >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | Mcast Flow ID TLV = 0x107 |S| Mcast Flow ID- >>> Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | AddrFamily | EncType | Mcast >>> source | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> | AddrFamily | EncType | Mcast >>> group | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+ >>> >>> Figure 4 >>> >>> Followed by the Target Type TLV. >>> >>> A Multicast Entry TLV (0x104) determines the (flow, port), >>> therefore >>> it will have a Flow ID TLV and a Target-Type TLV as its >>> sub TLVs, and >>> there will be as many Multicast Entry TLVs as the number >>> of flows on >>> the AN. >>> >>> We have an implementation running with these message types. >>> -- >>> Regards, >>> Aniruddha. A >>> _______________________________________________ >>> ANCP mailing list >>> ANCP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ancp >>> >>> 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 >>> ANCP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ancp >>> >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www.ietf.org/mailman/listinfo/ancp > --Apple-Mail-34--893003094 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable AN vs AN-->NAS.
Somewhat = similar to what is already done for the Delegated Bandwidth Query = Request/Response of ancp-mc-extensions-01.
Is this TLV = really = needed?

Thanks 

Fra= ncois



Begin = forwarded message:

From: = "BOCCI Matthew" <Matthew.Bocci@alcatel-luc= ent.com>
Date: 31 March 2009 17:51:37 = CEDT
To: "Aniruddha A (anira)" <anira@cisco.com>, <ancp@ietf.org>
Subject: = Re: [ANCP] ANCP messages for Multicast query and = report

=
This was discussed in San Francisco, and there seemed to be = agreement in
principle, but we would appreciate feedback on this = proposal on the list
from the = WG.

Matthew


-----Original = Message-----
From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] = On
Behalf Of Aniruddha A = (anira)
Sent: 06 March 2009 = 11:00
To: ancp@ietf.org
Subject: Re: [ANCP] ANCP messages for Multicast query = and report



Hi = All,

I propose the = following new ANCP message to get all ports on =
AN for a given Multicast flow = (S,G) :

- Request = message from NAS to AN to get all the ports where a =
multicast
=  flow is active.
=  The Mandatory Active-Flow-Req TLV is followed by the Flow-ID = TLV
 which identifies = which flow we are interested in.

=      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5 6 7 8 9 0 1
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     |        Type = (0x88-0C)         | =           Length =             &n= bsp;|
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | Vers  |  Sub  |MsgType=3D0x92 =   | Res   | =        Code =           |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | Partition ID  | =            Transact= ion Identifier =             |<= br>
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     |I|      SubMessage = Number      | =           Length =             &n= bsp;|
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     |     ActiveFlowReq TLV = =3D0x103  |    ActiveFlow-Length =          |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     |  Mcast Flow ID TLV =3D 0x107 =    |S|   Mcast Flow ID-Length =      |
= =     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | AddrFamily    | EncType =       |  Mcast source =             &n= bsp;   |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | AddrFamily    | EncType =       |  Mcast group =             &n= bsp;    |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+

- Report = message from AN to NAS to send all the ports for a =
particular = flow.
 The report uses a = new TLV - 0x108

=      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5 6 7 8 9 0 1
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     |        Type = (0x88-0C)         | =           Length =             &n= bsp;|
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | Vers  |  Sub  |MsgType=3D0x92 =    | Res   | =        Code =          |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | Partition ID  | =            Transact= ion Identifier =             |<= br>
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     |I|      SubMessage = Number      | =           Length =             &n= bsp;|
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     |ActiveFlow Target Ports =3D 0x108| =    ActiveFlow-Length =          |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     |  Mcast Flow ID TLV =3D 0x107 =    |S|   Mcast Flow ID-Length =      |
= =     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | AddrFamily    | EncType =       |  Mcast source =             &n= bsp;   |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | AddrFamily    | EncType =       |  Mcast group =             &n= bsp;    |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+

Followed by = one or more Target-Type TLV which identifies the = port

=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     |     Target-type-TLV=3D0x1000=    |   Target-TLV-Length =           |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | =            ID = type            | =   Circuit ID Length =           |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
    ~ =             &n= bsp;           &nbs= p;  Client-ID =             &n= bsp;           &nbs= p;~
    | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+


--
Regards,
Aniruddha. A

-----Original = Message-----
From: Maglione = Roberta [mailto:roberta.maglione@= telecomitalia.it]
Sent: = Thursday, February 05, 2009 9:19 PM
To: Aniruddha A (anira); ancp@ietf.org
Subject: RE: ANCP messages for Multicast query and = report

Hi = Aniruddha,
=        your proposal seems = interesting to me, but I have a comment:
section 3.4.3 of the ancp-framework draft defines 3 = different
types of reporting = function:
- report for one = Access Port;
- report for one = multicast flow;
- a global = report for one Access Node.

If my = understanding is correct, your proposal addresses 1 and =
3, do you plan to extend it = to cover also case 2?

Thanks and best = regards.
Roberta

-----Original = Message-----
From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] = On
Behalf Of Aniruddha A = (anira)
Sent: Monday, January = 12, 2009 6:46 PM
To: ancp@ietf.org
Subject: [ANCP] ANCP messages for Multicast query and = report

Hi = all,

In the ANCP = multicast extensions, there has to be a way For =
the NAS to query the AN for = the state of active multicast flows on it.

We propose the = following 2 new messages for this purpose:
-  Active-Flow Request
-  Active-Flow Report

The query from = the NAS can be for all flows on the AN or
flows active on a single port. Message Type 0x92 is = used.

Description and = message formats:

=  Active-Flow Request Message

=   The Active Flow Request message is sent by the NAS to the AN = to
  request = multicast flow status on the AN.  The payload contains = the
  following = TLVs:

  o =  The Active-Flow-Req TLV (0x103)
     A Mandatory = TLV.

  o =  The Target Type TLV.
=      Optional TLV, if present, request is for a = single port.

  On = receiving the Active Flow Request message, the AN MUST = respond
  with the = Active Flow Report containing the requested information = if
  the Multicast = capability has been negotiated.  The format of = the
  message is = shown below:

=      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5 6 7 8 9 0 1
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     |        Type = (0x88-0C)         | =           Length =             &n= bsp;|
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | Vers  |  Sub  |MsgType=3D0x92 =   | Res   | =        Code =           |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | Partition ID  | =            Transact= ion Identifier =             |<= br>
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     |I|      SubMessage = Number      | =           Length =             &n= bsp;|
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     |     ActiveFlowReq TLV = =3D0x103  |    ActiveFlow-Length =          |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     |     Target-type-TLV=3D0x1000=    |   Target-TLV-Length =           |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | =            ID = type            | =   Circuit ID Length =           |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
    ~ =             &n= bsp;           &nbs= p;  Client-ID =             &n= bsp;           &nbs= p;~
    | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+

=             &n= bsp;           &nbs= p;       Figure = 1

 Active-Flow Report = Message

=   The Active Flow Report message is sent from the AN to the = NAS in
  response = to the Active Flow Request message.  Active Flow = Report
  message = contains information on the requested multicast flows. =  The
  report = can be for a single port, or all ports depending on =
the = Target
  Type in = the request.

  o = Single Port Report

  If = the Active Flow Request had a specific port (the presence of = a
  Target Type = TLV), the response has the following format:

=      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5 6 7 8 9 0 1
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     |        Type = (0x88-0C)         | =           Length =             &n= bsp;|
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | Vers  |  Sub  |MsgType=3D0x92 =    | Res   | =        Code =          |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | Partition ID  | =            Transact= ion Identifier =             |<= br>
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     |I|      SubMessage = Number      | =           Length =             &n= bsp;|
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | ActiveFlowPortEntryTLV =3D0x105 | =    ActiveFlow-Length =          |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     |     Target-type-TLV=3D0x1000=    |   Target-TLV-Length =           |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | =            ID = type            | =   Circuit ID Length =           |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
    ~ =             &n= bsp;           &nbs= p;  Client-ID =             &n= bsp;           &nbs= p;~
    | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+

=             &n= bsp;           &nbs= p;       Figure = 2

  Followed by the Multicast Flow ID TLVs = (0x107), one for
each flow = on
  the port. =  The format of the Flow ID TLV is:

=      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5 6 7 8 9 0 1
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     |  Mcast Flow ID TLV =3D 0x107 =    |S|  Mcast Flow ID-Length =       |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | AddrFamily    | EncType =       |  Mcast source =             &n= bsp;   |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | AddrFamily    | EncType =       |  Mcast group =             &n= bsp;    |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+

=             &n= bsp;           &nbs= p;       Figure = 3

  S is the source flag, if set, multicast = source address MUST be
=   present (SSM).

 o =  Report for all ports

  If = the Active Flow Request did not specify a specific port =
(no = Target
  Type TLV), = the response will have the following format:

=      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5 6 7 8 9 0 1
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     |        Type = (0x88-0C)         | =           Length =             &n= bsp;|
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | Vers  |  Sub  |MsgType=3D0x92 =   | Res   | =        Code =           |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | Partition ID  | =            Transact= ion Identifier =             |<= br>
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     |I|      SubMessage = Number      | =           Length =             &n= bsp;|
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     |ActiveFlowMcastEntryTLV =3D0x104 | =    ActiveFlow-Length =          |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     |  Mcast Flow ID TLV =3D 0x107 =    |S|   Mcast Flow ID-Length =      |
= =     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | AddrFamily    | EncType =       |  Mcast source =             &n= bsp;   |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=     | AddrFamily    | EncType =       |  Mcast group =             &n= bsp;    |
=     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+

=             &n= bsp;           &nbs= p;       Figure = 4

  Followed by the Target Type = TLV.

  A = Multicast Entry TLV (0x104) determines the (flow, port), =
therefore
=   it will have a Flow ID TLV and a Target-Type TLV as its =
sub TLVs, = and
  there will be = as many Multicast Entry TLVs as the number
of flows on
=   the AN.

We have an = implementation running with these message = types.
--
Regards,
Aniruddha. A
_______________________________________________
ANCP mailing = list
ANCP@ietf.org
https://www.ietf.org/m= ailman/listinfo/ancp

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
ANCP@ietf.org
https://www.ietf.org/m= ailman/listinfo/ancp

___________________________________________= ____
ANCP mailing list
ANCP@ietf.org
https://www.ietf.org/m= ailman/listinfo/ancp


= --Apple-Mail-34--893003094-- From anira@cisco.com Thu Jun 25 03:50:59 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7F63A6B0B for ; Thu, 25 Jun 2009 03:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgH6fsivvxhj for ; Thu, 25 Jun 2009 03:50:57 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 100683A6957 for ; Thu, 25 Jun 2009 03:50:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,290,1243814400"; d="scan'208,217";a="180258564" Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by sj-iport-2.cisco.com with ESMTP; 25 Jun 2009 10:50:29 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5PAoSKv011334; Thu, 25 Jun 2009 18:50:28 +0800 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5PAo92L016905; Thu, 25 Jun 2009 10:50:28 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 16:20:18 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F582.BAF82C07" Date: Thu, 25 Jun 2009 16:20:17 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP Multicast I-D Changes Thread-Index: Acn0zp25sHFTi8AqRcG0LBe3PKV8GwAsOsew References: From: "Aniruddha A (anira)" To: "Francois Le Faucheur (flefauch)" , X-OriginalArrivalTime: 25 Jun 2009 10:50:18.0981 (UTC) FILETIME=[BB118150:01C9F582] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=66115; t=1245927028; x=1246791028; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=anira@cisco.com; z=From:=20=22Aniruddha=20A=20(anira)=22=20 |Subject:=20RE=3A=20ANCP=20Multicast=20I-D=20Changes |Sender:=20; bh=4HGgUrnO/f0PBBfQ633b+XGw44WDLAciCB94jNAAggI=; b=imiflogOoaQWbAYQUSDPKqlTyyvrSzPyggVvrXAVByyR82tRm3F79vivoq yEEtnFR3mcZpGRADr79WFCXyZIkoskUO04ppOPrPCtZdJIGSesR2Rwba4hl/ SQav1DGnUhoEuE1gFSMZ7iWu0OjW7Yz3lCtIwvPDk8PBhdOClXDOo=; Authentication-Results: hkg-dkim-2; header.From=anira@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); Subject: Re: [ANCP] ANCP Multicast I-D Changes X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 10:50:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9F582.BAF82C07 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois, =20 Active-Flow-Req TLV can be omitted, but then, what will be the message format for global report (for AN as a whole) ? Message with header only ? My initial proposal was to make Target-TLV optional, so in global report case, there will be Active-Flow-Req TLV only. =20 -- Regards, Aniruddha. A =20 ________________________________ From: Francois Le Faucheur (flefauch)=20 Sent: Wednesday, June 24, 2009 6:51 PM To: ancp@ietf.org; Aniruddha A (anira) Cc: Francois Le Faucheur (flefauch); Maglione Roberta; tom.taylor@rogers.com Taylor; Sanjay Wadhwa Subject: Fwd: ANCP Multicast I-D Changes Folks, I am drafting text to incorporate something based on the proposal below to support query by NAS about active multicast flows on AN. Now would be a good time to provide comments on this topic if you have any. I will propose using Message-Type 0x97 (since the earlier number are now allocated) Aniruddha, I don't quite see the role of the "Active-Flow-Req TLV" since it is always present in all "Request" messages from NAS and doe snot convey actual information. I am guessing this may have been included to distinguish the Request from the Response, but I think this can be easily inferred by the direction NAS-->AN vs AN-->NAS. Somewhat similar to what is already done for the Delegated Bandwidth Query Request/Response of ancp-mc-extensions-01. Is this TLV really needed? Thanks=20 Francois Begin forwarded message: From: "BOCCI Matthew" Date: 31 March 2009 17:51:37 CEDT To: "Aniruddha A (anira)" , Subject: Re: [ANCP] ANCP messages for Multicast query and report This was discussed in San Francisco, and there seemed to be agreement in principle, but we would appreciate feedback on this proposal on the list from the WG. =09 Matthew =09 =09 =09 -----Original Message----- =09 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On=20 =09 Behalf Of Aniruddha A (anira) =09 Sent: 06 March 2009 11:00 =09 To: ancp@ietf.org =09 Subject: Re: [ANCP] ANCP messages for Multicast query and report =09 Hi All, =09 I propose the following new ANCP message to get all ports on=20 =09 AN for a given Multicast flow (S,G) : =09 - Request message from NAS to AN to get all the ports where a=20 =09 multicast =09 flow is active. =09 The Mandatory Active-Flow-Req TLV is followed by the Flow-ID TLV =09 which identifies which flow we are interested in. =09 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Type (0x88-0C) | Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Vers | Sub |MsgType=3D0x92 | Res | Code | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Partition ID | Transaction Identifier | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 |I| SubMessage Number | Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | ActiveFlowReq TLV =3D0x103 | ActiveFlow-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Mcast Flow ID TLV =3D 0x107 |S| Mcast Flow ID-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | AddrFamily | EncType | Mcast source | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | AddrFamily | EncType | Mcast group | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 - Report message from AN to NAS to send all the ports for a=20 =09 particular flow. =09 The report uses a new TLV - 0x108=20 =09 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Type (0x88-0C) | Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Vers | Sub |MsgType=3D0x92 | Res | Code | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Partition ID | Transaction Identifier | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 |I| SubMessage Number | Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 |ActiveFlow Target Ports =3D 0x108| ActiveFlow-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Mcast Flow ID TLV =3D 0x107 |S| Mcast Flow ID-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | AddrFamily | EncType | Mcast source | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | AddrFamily | EncType | Mcast group | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 Followed by one or more Target-Type TLV which identifies the port =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Target-type-TLV=3D0x1000 | Target-TLV-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | ID type | Circuit ID Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | | =09 ~ Client-ID ~ =09 | | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 -- =09 Regards, =09 Aniruddha. A =09 -----Original Message----- =09 From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] =09 Sent: Thursday, February 05, 2009 9:19 PM =09 To: Aniruddha A (anira); ancp@ietf.org =09 Subject: RE: ANCP messages for Multicast query and report =09 Hi Aniruddha, =09 your proposal seems interesting to me, but I have a comment: =09 section 3.4.3 of the ancp-framework draft defines 3 different=20 =09 types of reporting function: =09 - report for one Access Port; =09 - report for one multicast flow; =09 - a global report for one Access Node. =09 If my understanding is correct, your proposal addresses 1 and=20 =09 3, do you plan to extend it to cover also case 2? =09 Thanks and best regards. =09 Roberta =09 -----Original Message----- =09 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On=20 =09 Behalf Of Aniruddha A (anira) =09 Sent: Monday, January 12, 2009 6:46 PM =09 To: ancp@ietf.org =09 Subject: [ANCP] ANCP messages for Multicast query and report =09 Hi all, =09 In the ANCP multicast extensions, there has to be a way For=20 =09 the NAS to query the AN for the state of active multicast flows on it. =09 We propose the following 2 new messages for this purpose: =09 - Active-Flow Request =09 - Active-Flow Report =09 The query from the NAS can be for all flows on the AN or=20 =09 flows active on a single port. Message Type 0x92 is used. =09 Description and message formats: =09 Active-Flow Request Message =09 The Active Flow Request message is sent by the NAS to the AN to =09 request multicast flow status on the AN. The payload contains the =09 following TLVs: =09 o The Active-Flow-Req TLV (0x103) =09 A Mandatory TLV. =09 o The Target Type TLV. =09 Optional TLV, if present, request is for a single port. =09 On receiving the Active Flow Request message, the AN MUST respond =09 with the Active Flow Report containing the requested information if =09 the Multicast capability has been negotiated. The format of the =09 message is shown below: =09 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Type (0x88-0C) | Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Vers | Sub |MsgType=3D0x92 | Res | Code | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Partition ID | Transaction Identifier | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 |I| SubMessage Number | Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | ActiveFlowReq TLV =3D0x103 | ActiveFlow-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Target-type-TLV=3D0x1000 | Target-TLV-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | ID type | Circuit ID Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | | =09 ~ Client-ID ~ =09 | | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 Figure 1 =09 Active-Flow Report Message =09 The Active Flow Report message is sent from the AN to the NAS in =09 response to the Active Flow Request message. Active Flow Report =09 message contains information on the requested multicast flows. The =09 report can be for a single port, or all ports depending on=20 =09 the Target =09 Type in the request. =09 o Single Port Report =09 If the Active Flow Request had a specific port (the presence of a =09 Target Type TLV), the response has the following format: =09 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Type (0x88-0C) | Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Vers | Sub |MsgType=3D0x92 | Res | Code | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Partition ID | Transaction Identifier | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 |I| SubMessage Number | Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | ActiveFlowPortEntryTLV =3D0x105 | ActiveFlow-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Target-type-TLV=3D0x1000 | Target-TLV-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | ID type | Circuit ID Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | | =09 ~ Client-ID ~ =09 | | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 Figure 2 =09 Followed by the Multicast Flow ID TLVs (0x107), one for=20 =09 each flow on =09 the port. The format of the Flow ID TLV is: =09 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Mcast Flow ID TLV =3D 0x107 |S| Mcast Flow ID-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | AddrFamily | EncType | Mcast source | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | AddrFamily | EncType | Mcast group | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 Figure 3 =09 S is the source flag, if set, multicast source address MUST be =09 present (SSM). =09 o Report for all ports =09 If the Active Flow Request did not specify a specific port=20 =09 (no Target =09 Type TLV), the response will have the following format: =09 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Type (0x88-0C) | Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Vers | Sub |MsgType=3D0x92 | Res | Code | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Partition ID | Transaction Identifier | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 |I| SubMessage Number | Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 |ActiveFlowMcastEntryTLV =3D0x104 | ActiveFlow-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Mcast Flow ID TLV =3D 0x107 |S| Mcast Flow ID-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | AddrFamily | EncType | Mcast source | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | AddrFamily | EncType | Mcast group | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 Figure 4 =09 Followed by the Target Type TLV. =09 A Multicast Entry TLV (0x104) determines the (flow, port),=20 =09 therefore =09 it will have a Flow ID TLV and a Target-Type TLV as its=20 =09 sub TLVs, and =09 there will be as many Multicast Entry TLVs as the number=20 =09 of flows on =09 the AN. =09 We have an implementation running with these message types. =09 -- =09 Regards, =09 Aniruddha. A =09 _______________________________________________ =09 ANCP mailing list =09 ANCP@ietf.org =09 https://www.ietf.org/mailman/listinfo/ancp =09 Questo messaggio e i suoi allegati sono indirizzati=20 =09 esclusivamente alle persone indicate. La diffusione, copia o=20 =09 qualsiasi altra azione derivante dalla conoscenza di queste=20 =09 informazioni sono rigorosamente vietate. Qualora abbiate=20 =09 ricevuto questo documento per errore siete cortesemente=20 =09 pregati di darne immediata comunicazione al mittente e di=20 =09 provvedere alla sua distruzione, Grazie. =09 This e-mail and any attachments is confidential and may=20 =09 contain privileged information intended for the addressee(s) only. =09 Dissemination, copying, printing or use by anybody else is=20 =09 unauthorised. =09 If you are not the intended recipient, please delete this=20 =09 message and any attachments and advise the sender by return=20 =09 e-mail, Thanks. =09 _______________________________________________ =09 ANCP mailing list =09 ANCP@ietf.org =09 https://www.ietf.org/mailman/listinfo/ancp =09 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp =09 ------_=_NextPart_001_01C9F582.BAF82C07 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Francois,
 
Active-Flow-Req = TLV can be=20 omitted, but then,  what will be the message format for global = report=20 (for AN as a whole) ?
Message with = header only=20 ?
My initial = proposal was to make=20 Target-TLV optional, so in global report case, there will be Active-Flow-Req TLV only.
 
--
Regards,
Aniruddha. A
 

From: Francois Le Faucheur = (flefauch)=20
Sent: Wednesday, June 24, 2009 6:51 PM
To: = ancp@ietf.org;=20 Aniruddha A (anira)
Cc: Francois Le Faucheur (flefauch); = Maglione=20 Roberta; tom.taylor@rogers.com Taylor; Sanjay Wadhwa
Subject: = Fwd:=20 ANCP Multicast I-D Changes

Folks,

I am drafting text to incorporate something based on the proposal = below to=20 support query by NAS about active multicast flows on AN.
Now would be a good time to provide comments on this = topic if you=20 have any.
I will propose using Message-Type 0x97 (since the earlier = number=20 are now allocated)

Aniruddha,
I don't quite see the role of the "Active-Flow-Req TLV" since it is = always=20 present in all "Request" messages from NAS and doe snot convey actual=20 information. I am guessing this may have been included to distinguish = the=20 Request from the Response, but I think this can be easily inferred=20 by the direction NAS-->AN vs AN-->NAS.
Somewhat similar to what is already done for the Delegated = Bandwidth Query=20 Request/Response of ancp-mc-extensions-01.
Is this TLV really needed?

Thanks 

Francois



Begin forwarded message:

From: "BOCCI = Matthew" <Matthew.Bocci@alcatel-lu= cent.com>
Date: 31 March = 2009 17:51:37=20 CEDT
To: "Aniruddha = A (anira)"=20 <anira@cisco.com>, = <ancp@ietf.org>
Subject: = Re: = [ANCP] ANCP=20 messages for Multicast query and report

This was discussed in San Francisco, and there seemed to be = agreement=20 in
principle, but we would appreciate feedback on this proposal = on the=20 list
from the WG.

Matthew


-----Original = Message-----
From: ancp-bounces@ietf.org = [mailto:ancp-bounces@ietf.org] = On=20
Behalf Of Aniruddha A = (anira)
Sent: 06 March 2009 11:00
To: ancp@ietf.org
Subject: Re: [ANCP] ANCP messages for = Multicast=20 query and report



Hi All,

I propose the following new ANCP message = to get=20 all ports on
AN for a given Multicast flow (S,G)=20 :

- Request message from NAS to AN to get = all the=20 ports where a
multicast
 flow is active.
 The Mandatory Active-Flow-Req TLV is = followed by the Flow-ID TLV
 which identifies which flow we are=20 interested in.

     0 1 2 3 4 5 = 6 7 8 9=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20        Type (0x88-0C)=20         |=20           Length = =             &= nbsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Vers  | =  Sub=20  |MsgType=3D0x92   | Res   |=20        Code=20 =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Partition ID =  |=20 =            Transac= tion=20 Identifier=20 =             |=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |I|=20      SubMessage Number=20      |=20           Length = =             &= nbsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20     ActiveFlowReq TLV =3D0x103  |=20    ActiveFlow-Length=20 =          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Mcast Flow = ID TLV=20 =3D 0x107    |S|   Mcast Flow ID-Length=20      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily=20    | EncType       |=20  Mcast source=20 =             &= nbsp;   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily=20    | EncType       |=20  Mcast group=20 =             &= nbsp;    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- Report message from AN to NAS to send = all the=20 ports for a
particular flow.
 The report uses a new TLV - 0x108=20

     0 1 2 3 4 5 = 6 7 8 9=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20        Type (0x88-0C)=20         |=20           Length = =             &= nbsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Vers  | =  Sub=20  |MsgType=3D0x92    | Res   |=20        Code=20 =          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Partition ID =  |=20 =            Transac= tion=20 Identifier=20 =             |=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |I|=20      SubMessage Number=20      |=20           Length = =             &= nbsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |ActiveFlow Target = Ports =3D=20 0x108|    ActiveFlow-Length=20 =          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Mcast Flow = ID TLV=20 =3D 0x107    |S|   Mcast Flow ID-Length=20      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily=20    | EncType       |=20  Mcast source=20 =             &= nbsp;   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily=20    | EncType       |=20  Mcast group=20 =             &= nbsp;    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Followed by one or more Target-Type TLV = which=20 identifies the port

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20     Target-type-TLV=3D0x1000 =    |=20   Target-TLV-Length=20 =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20 =            ID = type=20 =            |=20   Circuit ID Length=20 =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20 =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
    ~=20 =             &= nbsp;           &n= bsp;  Client-ID=20 =             &= nbsp;           &n= bsp;~
    |=20 =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


--
Regards,
Aniruddha. A

-----Original = Message-----
From: Maglione Roberta [mailto:roberta.maglione= @telecomitalia.it]
Sent: Thursday, February 05, 2009 9:19=20 PM
To: Aniruddha A (anira); ancp@ietf.org
Subject: RE: ANCP messages for Multicast = query and=20 report

Hi Aniruddha,
       your=20 proposal seems interesting to me, but I have a = comment:
section 3.4.3 of the ancp-framework draft = defines=20 3 different
types of reporting = function:
- report for one Access = Port;
- report for one multicast = flow;
- a global report for one Access=20 Node.

If my understanding is correct, your = proposal=20 addresses 1 and
3, do you plan to extend it to cover also = case=20 2?

Thanks and best regards.
Roberta

-----Original = Message-----
From: ancp-bounces@ietf.org = [mailto:ancp-bounces@ietf.org] = On=20
Behalf Of Aniruddha A = (anira)
Sent: Monday, January 12, 2009 6:46=20 PM
To: ancp@ietf.org
Subject: [ANCP] ANCP messages for = Multicast query=20 and report

Hi all,

In the ANCP multicast extensions, there = has to be=20 a way For
the NAS to query the AN for the state of = active=20 multicast flows on it.

We propose the following 2 new messages = for this=20 purpose:
-  Active-Flow = Request
-  Active-Flow = Report

The query from the NAS can be for all = flows on the=20 AN or
flows active on a single port. Message = Type 0x92=20 is used.

Description and message = formats:

 Active-Flow Request = Message

  The Active Flow Request = message is=20 sent by the NAS to the AN to
  request multicast flow status = on the=20 AN.  The payload contains the
  following = TLVs:

  o  The Active-Flow-Req = TLV=20 (0x103)
     A Mandatory=20 TLV.

  o  The Target Type=20 TLV.
     Optional = TLV, if=20 present, request is for a single port.

  On receiving the Active Flow = Request=20 message, the AN MUST respond
  with the Active Flow Report = containing=20 the requested information if
  the Multicast capability has = been=20 negotiated.  The format of the
  message is shown = below:

     0 1 2 3 4 5 = 6 7 8 9=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20        Type (0x88-0C)=20         |=20           Length = =             &= nbsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Vers  | =  Sub=20  |MsgType=3D0x92   | Res   |=20        Code=20 =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Partition ID =  |=20 =            Transac= tion=20 Identifier=20 =             |=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |I|=20      SubMessage Number=20      |=20           Length = =             &= nbsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20     ActiveFlowReq TLV =3D0x103  |=20    ActiveFlow-Length=20 =          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20     Target-type-TLV=3D0x1000 =    |=20   Target-TLV-Length=20 =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20 =            ID = type=20 =            |=20   Circuit ID Length=20 =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20 =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
    ~=20 =             &= nbsp;           &n= bsp;  Client-ID=20 =             &= nbsp;           &n= bsp;~
    |=20 =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          = ;            =           Figure=20 1

 Active-Flow Report = Message

  The Active Flow Report message = is sent=20 from the AN to the NAS in
  response to the Active Flow = Request=20 message.  Active Flow Report
  message contains information = on the=20 requested multicast flows.  The
  report can be for a single = port, or=20 all ports depending on
the Target
  Type in the = request.

  o Single Port = Report

  If the Active Flow Request had = a=20 specific port (the presence of a
  Target Type TLV), the response = has the=20 following format:

     0 1 2 3 4 5 = 6 7 8 9=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20        Type (0x88-0C)=20         |=20           Length = =             &= nbsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Vers  | =  Sub=20  |MsgType=3D0x92    | Res   |=20        Code=20 =          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Partition ID =  |=20 =            Transac= tion=20 Identifier=20 =             |=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |I|=20      SubMessage Number=20      |=20           Length = =             &= nbsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | = ActiveFlowPortEntryTLV=20 =3D0x105 |    ActiveFlow-Length=20 =          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20     Target-type-TLV=3D0x1000 =    |=20   Target-TLV-Length=20 =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20 =            ID = type=20 =            |=20   Circuit ID Length=20 =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20 =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
    ~=20 =             &= nbsp;           &n= bsp;  Client-ID=20 =             &= nbsp;           &n= bsp;~
    |=20 =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          = ;            =           Figure=20 2

  Followed by the Multicast Flow = ID TLVs=20 (0x107), one for
each flow on
  the port.  The format of = the Flow=20 ID TLV is:

     0 1 2 3 4 5 = 6 7 8 9=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Mcast Flow = ID TLV=20 =3D 0x107    |S|  Mcast Flow ID-Length=20       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily=20    | EncType       |=20  Mcast source=20 =             &= nbsp;   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily=20    | EncType       |=20  Mcast group=20 =             &= nbsp;    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          = ;            =           Figure=20 3

  S is the source flag, if set,=20 multicast source address MUST be
  present = (SSM).

 o  Report for all = ports

  If the Active Flow Request did = not=20 specify a specific port
(no Target
  Type TLV), the response will = have the=20 following format:

     0 1 2 3 4 5 = 6 7 8 9=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20        Type (0x88-0C)=20         |=20           Length = =             &= nbsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Vers  | =  Sub=20  |MsgType=3D0x92   | Res   |=20        Code=20 =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Partition ID =  |=20 =            Transac= tion=20 Identifier=20 =             |=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |I|=20      SubMessage Number=20      |=20           Length = =             &= nbsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |ActiveFlowMcastEntryTLV=20 =3D0x104 |    ActiveFlow-Length=20 =          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Mcast Flow = ID TLV=20 =3D 0x107    |S|   Mcast Flow ID-Length=20      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily=20    | EncType       |=20  Mcast source=20 =             &= nbsp;   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily=20    | EncType       |=20  Mcast group=20 =             &= nbsp;    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          = ;            =           Figure=20 4

  Followed by the Target Type=20 TLV.

  A Multicast Entry TLV (0x104)=20 determines the (flow, port),
therefore
  it will have a Flow ID TLV and = a=20 Target-Type TLV as its
sub TLVs, and
  there will be as many = Multicast Entry=20 TLVs as the number
of flows on
  the AN.

We have an implementation running with = these=20 message types.
--
Regards,
Aniruddha. A
_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www.ietf.org/= mailman/listinfo/ancp

Questo messaggio e i suoi allegati sono=20 indirizzati
esclusivamente alle persone indicate. La=20 diffusione, copia o
qualsiasi altra azione derivante dalla = conoscenza=20 di queste
informazioni sono rigorosamente vietate. = Qualora=20 abbiate
ricevuto questo documento per errore siete = cortesemente
pregati di darne immediata comunicazione = al=20 mittente e di
provvedere alla sua distruzione,=20 Grazie.

This e-mail and any attachments is = confidential=20 and may
contain privileged information intended = for the=20 addressee(s) only.
Dissemination, copying, printing or use by = anybody=20 else is
unauthorised.
If you are not the intended recipient, = please=20 delete this
message and any attachments and advise the = sender=20 by return
e-mail, Thanks.

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www.ietf.org/= mailman/listinfo/ancp

__________________________________________= _____
ANCP=20 mailing list
ANCP@ietf.org
https://www.ietf.org/= mailman/listinfo/ancp


------_=_NextPart_001_01C9F582.BAF82C07-- From HaagT@telekom.de Thu Jun 25 04:12:47 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2C73A6A4C for ; Thu, 25 Jun 2009 04:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WouO9SbLpFY for ; Thu, 25 Jun 2009 04:12:46 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id D4F9828C122 for ; Thu, 25 Jun 2009 04:12:43 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 25 Jun 2009 13:12:14 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 13:12:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F585.CA7FC803" Date: Thu, 25 Jun 2009 13:12:15 +0200 Message-ID: <5661758E3E93364685B91DD8272F2876016E84A3@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Topology discovery question Thread-Index: Acn0C8KG7qBrFyurRJSNtwJlC9T6ngAvTb1gAC6w5/A= References: From: To: , X-OriginalArrivalTime: 25 Jun 2009 11:12:14.0157 (UTC) FILETIME=[CAF96FD0:01C9F585] Cc: ancp@ietf.org, Keith.Monahan@ecitele.com, Mark.Dyga@ecitele.com Subject: Re: [ANCP] Topology discovery question X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 11:12:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9F585.CA7FC803 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Woj, Sidd, =20 I agree. =20 In any case a GSMP message is sent if a DSLAM comes up.=20 ANCP reports port status allways which means three different stati: up, down (idle), down (silent). =20 Regards Thomas =20 _____ =20 Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech Dec (wdec) Gesendet: Mittwoch, 24. Juni 2009 14:43 An: Sidd Aanand; ancp@ietf.org Cc: Keith A. Monahan; Mark Dyga Betreff: Re: [ANCP] Topology discovery question Hi, =20 well, each Port-up should be sent in a separate message, however note that since ANCP runs on TCP this doesn't actually matter much. =20 Cheers, Woj. _____ =20 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Sidd Aanand Sent: 23 June 2009 16:06 To: ancp@ietf.org Cc: Keith A. Monahan; Mark Dyga Subject: [ANCP] Topology discovery question Hi All, =20 Section 5.4.2 of the v05 ANCP draft says: Also, when the ANCP session first comes up, the DSLAM SHOULD transmit=20 a PORT UP message to the NAS for each line that is up.=20 Is the expectation that each PORT UP message is sent as a separate GSMP message or is the DSLAM expected to batch a set of PORT UP messages in a single GSMP message? If it is the latter, how does the message convey how many port up messages are contained within the single GSMP message? =20 Thanks, Sidd ------_=_NextPart_001_01C9F585.CA7FC803 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Woj, Sidd,
 
I agree.
 
In any case a GSMP message is sent if a DSLAM = comes up.
ANCP reports port status allways=20 which means three different stati: up, down = (idle), down=20 (silent).
 
Regards
Thomas
 

Von: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech Dec=20 (wdec)
Gesendet: Mittwoch, 24. Juni 2009 14:43
An: = Sidd=20 Aanand; ancp@ietf.org
Cc: Keith A. Monahan; Mark=20 Dyga
Betreff: Re: [ANCP] Topology discovery=20 question

Hi,
 
well, each Port-up should be sent in a separate message, = however note=20 that since ANCP runs on TCP this doesn't actually matter=20 much.
 
Cheers,
Woj.

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Sidd = Aanand
Sent:=20 23 June 2009 16:06
To: ancp@ietf.org
Cc: Keith A. = Monahan;=20 Mark Dyga
Subject: [ANCP] Topology discovery=20 question

Hi=20 All,
 
Section 5.4.2 of=20 the v05 ANCP draft says:
Also, when the ANCP =
session first comes up, the DSLAM SHOULD transmit 
a PORT UP message to the NAS for each line that is =
up.
Is = the expectation=20 that each PORT UP message is sent as a separate GSMP message or is the = DSLAM=20 expected to batch a set of PORT UP messages in a single GSMP message? = If it is=20 the latter, how does the message convey how many port up messages are=20 contained within the single GSMP message?
 
Thanks,
Sidd
------_=_NextPart_001_01C9F585.CA7FC803-- From flefauch@cisco.com Thu Jun 25 04:56:25 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8EA3A6AA9 for ; Thu, 25 Jun 2009 04:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.286 X-Spam-Level: X-Spam-Status: No, score=-10.286 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os0NJWO0N673 for ; Thu, 25 Jun 2009 04:56:21 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B67EC3A6828 for ; Thu, 25 Jun 2009 04:56:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,290,1243814400"; d="scan'208,217";a="43647555" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 25 Jun 2009 11:54:59 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5PBsxrp015665; Thu, 25 Jun 2009 13:54:59 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5PBsxpO001153; Thu, 25 Jun 2009 11:54:59 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jun 2009 13:54:59 +0200 Received: from ams-flefauch-8712.cisco.com ([10.55.161.195]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jun 2009 13:54:56 +0200 Message-Id: <7325015A-FA16-416A-8D07-F381880DCC05@cisco.com> From: Francois Le Faucheur IMAP To: "Aniruddha A (anira)" In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-4--811761556 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 25 Jun 2009 13:54:54 +0200 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 25 Jun 2009 11:54:56.0340 (UTC) FILETIME=[C2278940:01C9F58B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=65773; t=1245930899; x=1246794899; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20ANCP=20Multicast=20I-D=20Changes |Sender:=20; bh=90zzkfvGJ9mCOjyEhphbORN190119CfspiemEn2Hu3o=; b=tqKnyHH/Etp2Skejhrj/CFadnQNdxte3pqaxHdM6OOKq79696I7UekfBvi /GLEuD3uxFk2pZerdf6kB7S2EJ7ssXWRQ0099EuYSOHeiK+y5OCVO7lFdipS 3L7tyZbJDP; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ancp@ietf.org Subject: Re: [ANCP] ANCP Multicast I-D Changes X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 11:56:25 -0000 --Apple-Mail-4--811761556 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 25 Jun 2009, at 12:50, Aniruddha A (anira) wrote: > Hi Francois, > > Active-Flow-Req TLV can be omitted, but then, what will be the > message format for global report (for AN as a whole) ? > Message with header only ? yes. The TLVs effectively act as "scope limiters" ie it can limit scope of the query to one (or multiple) port, or to one or multiple flows. If absent, the query scope is not limited (ie query all flows on all ports). Is that OK? Francois > My initial proposal was to make Target-TLV optional, so in global > report case, there will be Active-Flow-Req TLV only. > > -- > Regards, > Aniruddha. A > > > From: Francois Le Faucheur (flefauch) > Sent: Wednesday, June 24, 2009 6:51 PM > To: ancp@ietf.org; Aniruddha A (anira) > Cc: Francois Le Faucheur (flefauch); Maglione Roberta; tom.taylor@rogers.com > Taylor; Sanjay Wadhwa > Subject: Fwd: ANCP Multicast I-D Changes > > Folks, > > I am drafting text to incorporate something based on the proposal > below to support query by NAS about active multicast flows on AN. > Now would be a good time to provide comments on this topic if you > have any. > I will propose using Message-Type 0x97 (since the earlier number are > now allocated) > > Aniruddha, > I don't quite see the role of the "Active-Flow-Req TLV" since it is > always present in all "Request" messages from NAS and doe snot > convey actual information. I am guessing this may have been included > to distinguish the Request from the Response, but I think this can > be easily inferred by the direction NAS-->AN vs AN-->NAS. > Somewhat similar to what is already done for the Delegated Bandwidth > Query Request/Response of ancp-mc-extensions-01. > Is this TLV really needed? > > Thanks > > Francois > >> >> >> Begin forwarded message: >> >>> From: "BOCCI Matthew" >>> Date: 31 March 2009 17:51:37 CEDT >>> To: "Aniruddha A (anira)" , >>> Subject: Re: [ANCP] ANCP messages for Multicast query and report >>> >>> This was discussed in San Francisco, and there seemed to be >>> agreement in >>> principle, but we would appreciate feedback on this proposal on >>> the list >>> from the WG. >>> >>> Matthew >>> >>> >>>> -----Original Message----- >>>> From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On >>>> Behalf Of Aniruddha A (anira) >>>> Sent: 06 March 2009 11:00 >>>> To: ancp@ietf.org >>>> Subject: Re: [ANCP] ANCP messages for Multicast query and report >>>> >>>> >>>> >>>> Hi All, >>>> >>>> I propose the following new ANCP message to get all ports on >>>> AN for a given Multicast flow (S,G) : >>>> >>>> - Request message from NAS to AN to get all the ports where a >>>> multicast >>>> flow is active. >>>> The Mandatory Active-Flow-Req TLV is followed by the Flow-ID TLV >>>> which identifies which flow we are interested in. >>>> >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 >>>> 0 1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Type (0x88-0C) | >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Vers | Sub |MsgType=0x92 | Res | >>>> Code | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Partition ID | Transaction >>>> Identifier | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> |I| SubMessage Number | >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | ActiveFlowReq TLV =0x103 | ActiveFlow- >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Mcast Flow ID TLV = 0x107 |S| Mcast Flow ID- >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | AddrFamily | EncType | Mcast >>>> source | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | AddrFamily | EncType | Mcast >>>> group | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> >>>> - Report message from AN to NAS to send all the ports for a >>>> particular flow. >>>> The report uses a new TLV - 0x108 >>>> >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 >>>> 0 1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Type (0x88-0C) | >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Vers | Sub |MsgType=0x92 | Res | >>>> Code | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Partition ID | Transaction >>>> Identifier | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> |I| SubMessage Number | >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> |ActiveFlow Target Ports = 0x108| ActiveFlow- >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Mcast Flow ID TLV = 0x107 |S| Mcast Flow ID- >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | AddrFamily | EncType | Mcast >>>> source | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | AddrFamily | EncType | Mcast >>>> group | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> >>>> Followed by one or more Target-Type TLV which identifies the port >>>> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Target-type-TLV=0x1000 | Target-TLV- >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | ID type | Circuit ID >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> >>>> | | >>>> ~ Client- >>>> ID ~ >>>> >>>> | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> >>>> >>>> -- >>>> Regards, >>>> Aniruddha. A >>>> >>>> -----Original Message----- >>>> From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] >>>> Sent: Thursday, February 05, 2009 9:19 PM >>>> To: Aniruddha A (anira); ancp@ietf.org >>>> Subject: RE: ANCP messages for Multicast query and report >>>> >>>> Hi Aniruddha, >>>> your proposal seems interesting to me, but I have a comment: >>>> section 3.4.3 of the ancp-framework draft defines 3 different >>>> types of reporting function: >>>> - report for one Access Port; >>>> - report for one multicast flow; >>>> - a global report for one Access Node. >>>> >>>> If my understanding is correct, your proposal addresses 1 and >>>> 3, do you plan to extend it to cover also case 2? >>>> >>>> Thanks and best regards. >>>> Roberta >>>> >>>> -----Original Message----- >>>> From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On >>>> Behalf Of Aniruddha A (anira) >>>> Sent: Monday, January 12, 2009 6:46 PM >>>> To: ancp@ietf.org >>>> Subject: [ANCP] ANCP messages for Multicast query and report >>>> >>>> Hi all, >>>> >>>> In the ANCP multicast extensions, there has to be a way For >>>> the NAS to query the AN for the state of active multicast flows >>>> on it. >>>> >>>> We propose the following 2 new messages for this purpose: >>>> - Active-Flow Request >>>> - Active-Flow Report >>>> >>>> The query from the NAS can be for all flows on the AN or >>>> flows active on a single port. Message Type 0x92 is used. >>>> >>>> Description and message formats: >>>> >>>> Active-Flow Request Message >>>> >>>> The Active Flow Request message is sent by the NAS to the AN to >>>> request multicast flow status on the AN. The payload contains >>>> the >>>> following TLVs: >>>> >>>> o The Active-Flow-Req TLV (0x103) >>>> A Mandatory TLV. >>>> >>>> o The Target Type TLV. >>>> Optional TLV, if present, request is for a single port. >>>> >>>> On receiving the Active Flow Request message, the AN MUST respond >>>> with the Active Flow Report containing the requested >>>> information if >>>> the Multicast capability has been negotiated. The format of the >>>> message is shown below: >>>> >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 >>>> 0 1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Type (0x88-0C) | >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Vers | Sub |MsgType=0x92 | Res | >>>> Code | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Partition ID | Transaction >>>> Identifier | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> |I| SubMessage Number | >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | ActiveFlowReq TLV =0x103 | ActiveFlow- >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Target-type-TLV=0x1000 | Target-TLV- >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | ID type | Circuit ID >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> >>>> | | >>>> ~ Client- >>>> ID ~ >>>> >>>> | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> >>>> Figure 1 >>>> >>>> Active-Flow Report Message >>>> >>>> The Active Flow Report message is sent from the AN to the NAS in >>>> response to the Active Flow Request message. Active Flow Report >>>> message contains information on the requested multicast flows. >>>> The >>>> report can be for a single port, or all ports depending on >>>> the Target >>>> Type in the request. >>>> >>>> o Single Port Report >>>> >>>> If the Active Flow Request had a specific port (the presence of a >>>> Target Type TLV), the response has the following format: >>>> >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 >>>> 0 1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Type (0x88-0C) | >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Vers | Sub |MsgType=0x92 | Res | >>>> Code | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Partition ID | Transaction >>>> Identifier | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> |I| SubMessage Number | >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | ActiveFlowPortEntryTLV =0x105 | ActiveFlow- >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Target-type-TLV=0x1000 | Target-TLV- >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | ID type | Circuit ID >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> >>>> | | >>>> ~ Client- >>>> ID ~ >>>> >>>> | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> >>>> Figure 2 >>>> >>>> Followed by the Multicast Flow ID TLVs (0x107), one for >>>> each flow on >>>> the port. The format of the Flow ID TLV is: >>>> >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 >>>> 0 1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Mcast Flow ID TLV = 0x107 |S| Mcast Flow ID- >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | AddrFamily | EncType | Mcast >>>> source | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | AddrFamily | EncType | Mcast >>>> group | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> >>>> Figure 3 >>>> >>>> S is the source flag, if set, multicast source address MUST be >>>> present (SSM). >>>> >>>> o Report for all ports >>>> >>>> If the Active Flow Request did not specify a specific port >>>> (no Target >>>> Type TLV), the response will have the following format: >>>> >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 >>>> 0 1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Type (0x88-0C) | >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Vers | Sub |MsgType=0x92 | Res | >>>> Code | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Partition ID | Transaction >>>> Identifier | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> |I| SubMessage Number | >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> |ActiveFlowMcastEntryTLV =0x104 | ActiveFlow- >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | Mcast Flow ID TLV = 0x107 |S| Mcast Flow ID- >>>> Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | AddrFamily | EncType | Mcast >>>> source | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> | AddrFamily | EncType | Mcast >>>> group | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> +-+ >>>> >>>> Figure 4 >>>> >>>> Followed by the Target Type TLV. >>>> >>>> A Multicast Entry TLV (0x104) determines the (flow, port), >>>> therefore >>>> it will have a Flow ID TLV and a Target-Type TLV as its >>>> sub TLVs, and >>>> there will be as many Multicast Entry TLVs as the number >>>> of flows on >>>> the AN. >>>> >>>> We have an implementation running with these message types. >>>> -- >>>> Regards, >>>> Aniruddha. A >>>> _______________________________________________ >>>> ANCP mailing list >>>> ANCP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ancp >>>> >>>> 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 >>>> ANCP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ancp >>>> >>> _______________________________________________ >>> ANCP mailing list >>> ANCP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ancp >> > --Apple-Mail-4--811761556 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi,

On 25 Jun = 2009, at 12:50, Aniruddha A (anira) wrote:

Hi = Francois,
 
Active-Flow-Req TLV can be = omitted, but then,  what will be the message format for global = report (for AN as a whole) ?
Message with header only = ?

yes.
The TLVs effectively act as "scope limiters" ie it can limit scope of = the query to one (or multiple) port, or to one or multiple flows. If = absent, the query scope is not limited (ie query all flows on all = ports).

Is that = OK?

Francois


<= br>
My initial = proposal was to make Target-TLV optional, so in global report case, = there will be Active-Flow-Req TLV = only.
 
--
=
Regards,
=
Aniruddha. = A
 

=
From: = Francois Le Faucheur (flefauch)
Sent: Wednesday, June 24, = 2009 6:51 PM
To: ancp@ietf.org; Aniruddha A = (anira)
Cc: Francois Le Faucheur (flefauch); Maglione Roberta; = tom.taylor@rogers.com = Taylor; Sanjay Wadhwa
Subject: Fwd: ANCP Multicast I-D = Changes

Folks,

I am drafting text to incorporate = something based on the proposal below to support query by NAS about = active multicast flows on AN.
Now would be a good = time to provide comments on this topic if you have any.
I = will propose using Message-Type 0x97 (since the earlier number = are now allocated)

Aniruddha,
I = don't quite see the role of the "Active-Flow-Req TLV" since it is always = present in all "Request" messages from NAS and doe snot convey actual = information. I am guessing this may have been included to distinguish = the Request from the Response, but I think this can be easily inferred = by the direction NAS-->AN vs AN-->NAS.
=
Somewhat similar to what is already done for the Delegated = Bandwidth Query Request/Response of ancp-mc-extensions-01.
=
Is this TLV really needed?

=
Thanks 

Francois
=



Begin forwarded = message:

From: "BOCCI Matthew" <Matthew.Bocci@alcatel-luc= ent.com>
Date: 31 March 2009 17:51:37 = CEDT
To: "Aniruddha A (anira)" <anira@cisco.com>, <ancp@ietf.org>
Subject: = Re: [ANCP] ANCP messages for Multicast query and = report

This was discussed in San Francisco, and = there seemed to be agreement in
principle, but we would = appreciate feedback on this proposal on the list
from the = WG.

Matthew


-----Original = Message-----
From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] = On
Behalf Of = Aniruddha A (anira)
Sent: = 06 March 2009 11:00
To: ancp@ietf.org
=
Subject: Re: [ANCP] ANCP messages for = Multicast query and report



Hi = All,

=
I propose the following new ANCP message to = get all ports on
AN = for a given Multicast flow (S,G) :

- Request = message from NAS to AN to get all the ports where a =
multicast
=
 flow is active.
=
 The Mandatory Active-Flow-Req TLV is = followed by the Flow-ID TLV
 which identifies which flow we are interested = in.

=
     0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | =        Type (0x88-0C) =         | =           Length =             &n= bsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Vers  |  Sub =  |MsgType=3D0x92   | Res   | =        Code =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Partition ID  | =            Transact= ion Identifier =             |<= br>
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |I| =      SubMessage Number =      | =           Length =             &n= bsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | =     ActiveFlowReq TLV =3D0x103  | =    ActiveFlow-Length =          |
=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Mcast Flow ID TLV =3D = 0x107    |S|   Mcast Flow ID-Length =      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily =    | EncType       | =  Mcast source =             &n= bsp;   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily =    | EncType       | =  Mcast group =             &n= bsp;    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- Report = message from AN to NAS to send all the ports for a =
particular = flow.
 The report = uses a new TLV - 0x108

     0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | =        Type (0x88-0C) =         | =           Length =             &n= bsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Vers  |  Sub =  |MsgType=3D0x92    | Res   | =        Code =          |
=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Partition ID  | =            Transact= ion Identifier =             |<= br>
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |I| =      SubMessage Number =      | =           Length =             &n= bsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |ActiveFlow Target Ports =3D = 0x108|    ActiveFlow-Length =          |
=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Mcast Flow ID TLV =3D = 0x107    |S|   Mcast Flow ID-Length =      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily =    | EncType       | =  Mcast source =             &n= bsp;   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily =    | EncType       | =  Mcast group =             &n= bsp;    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Followed by = one or more Target-Type TLV which identifies the = port

=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | =     Target-type-TLV=3D0x1000    | =   Target-TLV-Length =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | =            ID = type =            | =   Circuit ID Length =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
    ~ =             &n= bsp;           &nbs= p;  Client-ID =             &n= bsp;           &nbs= p;~
    | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+


--
Regards,
Aniruddha. A

-----Original= Message-----
From: = Maglione Roberta [mailto:roberta.maglione@= telecomitalia.it]
Sent: = Thursday, February 05, 2009 9:19 PM
To: Aniruddha A (anira); ancp@ietf.org
=
Subject: RE: ANCP messages for Multicast query = and report

Hi = Aniruddha,
       your = proposal seems interesting to me, but I have a comment:
=
section 3.4.3 of the ancp-framework draft = defines 3 different
types of reporting function:
=
- report for one Access Port;
=
- report for one multicast = flow;
- a global report = for one Access Node.

If my = understanding is correct, your proposal addresses 1 and =
3, do you plan to extend = it to cover also case 2?

Thanks and = best regards.
Roberta

-----Original= Message-----
From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] = On
Behalf Of = Aniruddha A (anira)
Sent: = Monday, January 12, 2009 6:46 PM
To: ancp@ietf.org
=
Subject: [ANCP] ANCP messages for Multicast = query and report

Hi = all,

=
In the ANCP multicast extensions, there has to = be a way For
the = NAS to query the AN for the state of active multicast flows on = it.

=
We propose the following 2 new messages for = this purpose:
- =  Active-Flow Request
- =  Active-Flow Report

The query = from the NAS can be for all flows on the AN or
=
flows active on a single port. Message Type = 0x92 is used.

Description = and message formats:

 Active-Flow Request Message
=

  The Active Flow Request message is sent = by the NAS to the AN to
  request multicast flow status on the AN. =  The payload contains the
  following TLVs:
=

  o  The Active-Flow-Req TLV = (0x103)
     A Mandatory = TLV.

=
  o  The Target Type = TLV.
     Optional TLV, if = present, request is for a single port.

  On receiving the Active Flow Request = message, the AN MUST respond
  with the Active Flow Report containing = the requested information if
  the Multicast capability has been = negotiated.  The format of the
  message is shown below:
=

     0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | =        Type (0x88-0C) =         | =           Length =             &n= bsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Vers  |  Sub =  |MsgType=3D0x92   | Res   | =        Code =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Partition ID  | =            Transact= ion Identifier =             |<= br>
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |I| =      SubMessage Number =      | =           Length =             &n= bsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | =     ActiveFlowReq TLV =3D0x103  | =    ActiveFlow-Length =          |
=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | =     Target-type-TLV=3D0x1000    | =   Target-TLV-Length =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | =            ID = type =            | =   Circuit ID Length =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
    ~ =             &n= bsp;           &nbs= p;  Client-ID =             &n= bsp;           &nbs= p;~
    | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          =             &n= bsp;         Figure = 1

=
 Active-Flow Report = Message

=
  The Active Flow Report message = is sent from the AN to the NAS in
  response to the Active Flow Request = message.  Active Flow Report
  message contains information on the = requested multicast flows.  The
  report can be for a single port, or all = ports depending on
the = Target
  Type in = the request.

  o= Single Port Report

  If the Active Flow Request had a = specific port (the presence of a
  Target Type TLV), the response has the = following format:

     0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | =        Type (0x88-0C) =         | =           Length =             &n= bsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Vers  |  Sub =  |MsgType=3D0x92    | Res   | =        Code =          |
=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Partition ID  | =            Transact= ion Identifier =             |<= br>
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |I| =      SubMessage Number =      | =           Length =             &n= bsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | ActiveFlowPortEntryTLV = =3D0x105 |    ActiveFlow-Length =          |
=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | =     Target-type-TLV=3D0x1000    | =   Target-TLV-Length =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | =            ID = type =            | =   Circuit ID Length =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
    ~ =             &n= bsp;           &nbs= p;  Client-ID =             &n= bsp;           &nbs= p;~
    | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          =             &n= bsp;         Figure = 2

=
  Followed by the Multicast Flow ID = TLVs (0x107), one for
each flow on
  the port.  The format of the Flow = ID TLV is:

=
     0 1 2 3 4 5 = 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Mcast Flow ID TLV =3D = 0x107    |S|  Mcast Flow ID-Length =       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily =    | EncType       | =  Mcast source =             &n= bsp;   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily =    | EncType       | =  Mcast group =             &n= bsp;    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          =             &n= bsp;         Figure = 3

=
  S is the source flag, if set, = multicast source address MUST be
  present (SSM).

 o =  Report for all ports

  If the Active Flow Request did not = specify a specific port
(no= Target
  Type = TLV), the response will have the following = format:

=
     0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | =        Type (0x88-0C) =         | =           Length =             &n= bsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Vers  |  Sub =  |MsgType=3D0x92   | Res   | =        Code =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Partition ID  | =            Transact= ion Identifier =             |<= br>
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |I| =      SubMessage Number =      | =           Length =             &n= bsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |ActiveFlowMcastEntryTLV = =3D0x104 |    ActiveFlow-Length =          |
=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Mcast Flow ID TLV =3D = 0x107    |S|   Mcast Flow ID-Length =      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily =    | EncType       | =  Mcast source =             &n= bsp;   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily =    | EncType       | =  Mcast group =             &n= bsp;    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          =             &n= bsp;         Figure = 4

=
  Followed by the Target Type = TLV.

=
  A Multicast Entry TLV (0x104) = determines the (flow, port),
therefore
  it will have a Flow ID TLV and a = Target-Type TLV as its
sub = TLVs, and
  there = will be as many Multicast Entry TLVs as the number =
of flows = on
  the = AN.

=
We have an implementation running with these = message types.
--
Regards,
Aniruddha. A
_______________________________________________
ANCP mailing list
=
ANCP@ietf.org
=
https://www.ietf.org/m= ailman/listinfo/ancp

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
=
ANCP@ietf.org
=
https://www.ietf.org/m= ailman/listinfo/ancp

___________________________________________= ____
ANCP mailing list
ANCP@ietf.org
https://www.ietf.org/m= ailman/listinfo/ancp



= --Apple-Mail-4--811761556-- From anira@cisco.com Thu Jun 25 10:52:04 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598643A696A for ; Thu, 25 Jun 2009 10:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eq4ppnpIq5R7 for ; Thu, 25 Jun 2009 10:52:01 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 77F783A68DC for ; Thu, 25 Jun 2009 10:52:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,292,1243814400"; d="scan'208,217";a="38307770" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 25 Jun 2009 17:46:44 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5PHki5g015625; Thu, 25 Jun 2009 10:46:44 -0700 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n5PHkgD9028963; Thu, 25 Jun 2009 17:46:43 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 23:16:41 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F5BC.E5B7D7E7" Date: Thu, 25 Jun 2009 23:16:38 +0530 Message-ID: In-Reply-To: <7325015A-FA16-416A-8D07-F381880DCC05@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP Multicast I-D Changes Thread-Index: Acn1i8XhkeYFsTDgQmSKG4qQ0OcKjgAMNlxg References: <7325015A-FA16-416A-8D07-F381880DCC05@cisco.com> From: "Aniruddha A (anira)" To: "Francois Le Faucheur (flefauch)" X-OriginalArrivalTime: 25 Jun 2009 17:46:41.0685 (UTC) FILETIME=[E5EB9C50:01C9F5BC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=71101; t=1245952004; x=1246816004; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=anira@cisco.com; z=From:=20=22Aniruddha=20A=20(anira)=22=20 |Subject:=20RE=3A=20ANCP=20Multicast=20I-D=20Changes |Sender:=20; bh=p04zjb/jpfliE/02CLIMhXTWWnt0rJRV3CNEJcfDVqk=; b=0wfl1DWS7Re+tPVz3a6beFMCUIAp0mXwnRmh60fCAnIEmRM3XK3X/3urTT aUkMtUzaCdwU/ieZIGlv1jx2x59THehcPJ76NXNDSH59grmT/A1RBUhLz8cL zIr+3Dc4Om; Authentication-Results: sj-dkim-2; header.From=anira@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: ancp@ietf.org Subject: Re: [ANCP] ANCP Multicast I-D Changes X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 17:52:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9F5BC.E5B7D7E7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois, =20 Ok. =20 -- Regards, Aniruddha. A =20 ________________________________ From: Francois Le Faucheur (flefauch)=20 Sent: Thursday, June 25, 2009 5:25 PM To: Aniruddha A (anira) Cc: Francois Le Faucheur (flefauch); ancp@ietf.org; Maglione Roberta; tom.taylor@rogers.com; Sanjay Wadhwa; Shridhar Rao (shrirao) Subject: Re: ANCP Multicast I-D Changes Hi,=20 On 25 Jun 2009, at 12:50, Aniruddha A (anira) wrote: Hi Francois, =20 Active-Flow-Req TLV can be omitted, but then, what will be the message format for global report (for AN as a whole) ? Message with header only ? yes. The TLVs effectively act as "scope limiters" ie it can limit scope of the query to one (or multiple) port, or to one or multiple flows. If absent, the query scope is not limited (ie query all flows on all ports). Is that OK? Francois My initial proposal was to make Target-TLV optional, so in global report case, there will be Active-Flow-Req TLV only. =20 -- Regards, Aniruddha. A =20 =09 =09 ________________________________ From: Francois Le Faucheur (flefauch)=20 Sent: Wednesday, June 24, 2009 6:51 PM To: ancp@ietf.org; Aniruddha A (anira) Cc: Francois Le Faucheur (flefauch); Maglione Roberta; tom.taylor@rogers.com Taylor; Sanjay Wadhwa Subject: Fwd: ANCP Multicast I-D Changes =09 =09 Folks, =09 =09 I am drafting text to incorporate something based on the proposal below to support query by NAS about active multicast flows on AN. Now would be a good time to provide comments on this topic if you have any. I will propose using Message-Type 0x97 (since the earlier number are now allocated) Aniruddha, I don't quite see the role of the "Active-Flow-Req TLV" since it is always present in all "Request" messages from NAS and doe snot convey actual information. I am guessing this may have been included to distinguish the Request from the Response, but I think this can be easily inferred by the direction NAS-->AN vs AN-->NAS. Somewhat similar to what is already done for the Delegated Bandwidth Query Request/Response of ancp-mc-extensions-01. Is this TLV really needed? Thanks=20 Francois Begin forwarded message: From: "BOCCI Matthew" Date: 31 March 2009 17:51:37 CEDT To: "Aniruddha A (anira)" , Subject: Re: [ANCP] ANCP messages for Multicast query and report This was discussed in San Francisco, and there seemed to be agreement in principle, but we would appreciate feedback on this proposal on the list from the WG. =09 Matthew =09 =09 =09 -----Original Message----- =09 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On=20 =09 Behalf Of Aniruddha A (anira) =09 Sent: 06 March 2009 11:00 =09 To: ancp@ietf.org =09 Subject: Re: [ANCP] ANCP messages for Multicast query and report =09 Hi All, =09 I propose the following new ANCP message to get all ports on=20 =09 AN for a given Multicast flow (S,G) : =09 - Request message from NAS to AN to get all the ports where a=20 =09 multicast =09 flow is active. =09 The Mandatory Active-Flow-Req TLV is followed by the Flow-ID TLV =09 which identifies which flow we are interested in. =09 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Type (0x88-0C) | Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Vers | Sub |MsgType=3D0x92 | Res | Code | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Partition ID | Transaction Identifier | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 |I| SubMessage Number | Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | ActiveFlowReq TLV =3D0x103 | ActiveFlow-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Mcast Flow ID TLV =3D 0x107 |S| Mcast Flow ID-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | AddrFamily | EncType | Mcast source | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | AddrFamily | EncType | Mcast group | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 - Report message from AN to NAS to send all the ports for a=20 =09 particular flow. =09 The report uses a new TLV - 0x108=20 =09 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Type (0x88-0C) | Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Vers | Sub |MsgType=3D0x92 | Res | Code | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Partition ID | Transaction Identifier | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 |I| SubMessage Number | Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 |ActiveFlow Target Ports =3D 0x108| ActiveFlow-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Mcast Flow ID TLV =3D 0x107 |S| Mcast Flow ID-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | AddrFamily | EncType | Mcast source | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | AddrFamily | EncType | Mcast group | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 Followed by one or more Target-Type TLV which identifies the port =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Target-type-TLV=3D0x1000 | Target-TLV-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | ID type | Circuit ID Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | | =09 ~ Client-ID ~ =09 | | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 -- =09 Regards, =09 Aniruddha. A =09 -----Original Message----- =09 From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] =09 Sent: Thursday, February 05, 2009 9:19 PM =09 To: Aniruddha A (anira); ancp@ietf.org =09 Subject: RE: ANCP messages for Multicast query and report =09 Hi Aniruddha, =09 your proposal seems interesting to me, but I have a comment: =09 section 3.4.3 of the ancp-framework draft defines 3 different=20 =09 types of reporting function: =09 - report for one Access Port; =09 - report for one multicast flow; =09 - a global report for one Access Node. =09 If my understanding is correct, your proposal addresses 1 and=20 =09 3, do you plan to extend it to cover also case 2? =09 Thanks and best regards. =09 Roberta =09 -----Original Message----- =09 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On=20 =09 Behalf Of Aniruddha A (anira) =09 Sent: Monday, January 12, 2009 6:46 PM =09 To: ancp@ietf.org =09 Subject: [ANCP] ANCP messages for Multicast query and report =09 Hi all, =09 In the ANCP multicast extensions, there has to be a way For=20 =09 the NAS to query the AN for the state of active multicast flows on it. =09 We propose the following 2 new messages for this purpose: =09 - Active-Flow Request =09 - Active-Flow Report =09 The query from the NAS can be for all flows on the AN or=20 =09 flows active on a single port. Message Type 0x92 is used. =09 Description and message formats: =09 Active-Flow Request Message =09 The Active Flow Request message is sent by the NAS to the AN to =09 request multicast flow status on the AN. The payload contains the =09 following TLVs: =09 o The Active-Flow-Req TLV (0x103) =09 A Mandatory TLV. =09 o The Target Type TLV. =09 Optional TLV, if present, request is for a single port. =09 On receiving the Active Flow Request message, the AN MUST respond =09 with the Active Flow Report containing the requested information if =09 the Multicast capability has been negotiated. The format of the =09 message is shown below: =09 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Type (0x88-0C) | Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Vers | Sub |MsgType=3D0x92 | Res | Code | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Partition ID | Transaction Identifier | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 |I| SubMessage Number | Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | ActiveFlowReq TLV =3D0x103 | ActiveFlow-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Target-type-TLV=3D0x1000 | Target-TLV-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | ID type | Circuit ID Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | | =09 ~ Client-ID ~ =09 | | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 Figure 1 =09 Active-Flow Report Message =09 The Active Flow Report message is sent from the AN to the NAS in =09 response to the Active Flow Request message. Active Flow Report =09 message contains information on the requested multicast flows. The =09 report can be for a single port, or all ports depending on=20 =09 the Target =09 Type in the request. =09 o Single Port Report =09 If the Active Flow Request had a specific port (the presence of a =09 Target Type TLV), the response has the following format: =09 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Type (0x88-0C) | Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Vers | Sub |MsgType=3D0x92 | Res | Code | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Partition ID | Transaction Identifier | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 |I| SubMessage Number | Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | ActiveFlowPortEntryTLV =3D0x105 | ActiveFlow-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Target-type-TLV=3D0x1000 | Target-TLV-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | ID type | Circuit ID Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | | =09 ~ Client-ID ~ =09 | | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 Figure 2 =09 Followed by the Multicast Flow ID TLVs (0x107), one for=20 =09 each flow on =09 the port. The format of the Flow ID TLV is: =09 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Mcast Flow ID TLV =3D 0x107 |S| Mcast Flow ID-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | AddrFamily | EncType | Mcast source | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | AddrFamily | EncType | Mcast group | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 Figure 3 =09 S is the source flag, if set, multicast source address MUST be =09 present (SSM). =09 o Report for all ports =09 If the Active Flow Request did not specify a specific port=20 =09 (no Target =09 Type TLV), the response will have the following format: =09 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Type (0x88-0C) | Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Vers | Sub |MsgType=3D0x92 | Res | Code | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Partition ID | Transaction Identifier | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 |I| SubMessage Number | Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 |ActiveFlowMcastEntryTLV =3D0x104 | ActiveFlow-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Mcast Flow ID TLV =3D 0x107 |S| Mcast Flow ID-Length | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | AddrFamily | EncType | Mcast source | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | AddrFamily | EncType | Mcast group | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 Figure 4 =09 Followed by the Target Type TLV. =09 A Multicast Entry TLV (0x104) determines the (flow, port),=20 =09 therefore =09 it will have a Flow ID TLV and a Target-Type TLV as its=20 =09 sub TLVs, and =09 there will be as many Multicast Entry TLVs as the number=20 =09 of flows on =09 the AN. =09 We have an implementation running with these message types. =09 -- =09 Regards, =09 Aniruddha. A =09 =09 _______________________________________________ =09 ANCP mailing list =09 ANCP@ietf.org =09 =09 https://www.ietf.org/mailman/listinfo/ancp =09 Questo messaggio e i suoi allegati sono indirizzati=20 =09 esclusivamente alle persone indicate. La diffusione, copia o=20 =09 qualsiasi altra azione derivante dalla conoscenza di queste=20 =09 informazioni sono rigorosamente vietate. Qualora abbiate=20 =09 ricevuto questo documento per errore siete cortesemente=20 =09 pregati di darne immediata comunicazione al mittente e di=20 =09 provvedere alla sua distruzione, Grazie. =09 This e-mail and any attachments is confidential and may=20 =09 contain privileged information intended for the addressee(s) only. =09 Dissemination, copying, printing or use by anybody else is=20 =09 unauthorised. =09 If you are not the intended recipient, please delete this=20 =09 message and any attachments and advise the sender by return=20 =09 e-mail, Thanks. =09 =09 _______________________________________________ =09 ANCP mailing list =09 ANCP@ietf.org =09 =09 https://www.ietf.org/mailman/listinfo/ancp =09 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp =09 ------_=_NextPart_001_01C9F5BC.E5B7D7E7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Francois,
 
Ok.
 
--
Regards,
Aniruddha. A
 

From: Francois Le Faucheur = (flefauch)=20
Sent: Thursday, June 25, 2009 5:25 PM
To: Aniruddha = A=20 (anira)
Cc: Francois Le Faucheur (flefauch); ancp@ietf.org; = Maglione=20 Roberta; tom.taylor@rogers.com; Sanjay Wadhwa; Shridhar Rao=20 (shrirao)
Subject: Re: ANCP Multicast I-D = Changes

Hi,

On 25 Jun 2009, at 12:50, Aniruddha A (anira) wrote:
Hi=20 Francois,
 
Active-Flow-Req = TLV can be=20 omitted, but then,  what will be the message format for = global=20 report (for AN as a whole) ?
Message with = header only=20 ?

yes.
The TLVs effectively act as "scope limiters" ie it can limit scope = of the=20 query to one (or multiple) port, or to one or multiple flows. If absent, = the=20 query scope is not limited (ie query all flows on all ports).

Is that OK?

Francois



My initial = proposal was to=20 make Target-TLV optional, so in global report case, there will be = Active-Flow-Req TLV only.
 
--
Regards,
Aniruddha. A
 

From: Francois Le Faucheur = (flefauch)=20
Sent: Wednesday, June 24, 2009 6:51 PM
To: ancp@ietf.org; Aniruddha A=20 (anira)
Cc: Francois Le Faucheur (flefauch); Maglione = Roberta; tom.taylor@rogers.com = Taylor; Sanjay=20 Wadhwa
Subject: Fwd: ANCP Multicast I-D = Changes

Folks,

I am drafting text to incorporate something based on the proposal = below=20 to support query by NAS about active multicast flows on AN.
Now would be a good time to provide comments on this = topic if=20 you have any.
I will propose using Message-Type 0x97 = (since the earlier=20 number are now allocated)

Aniruddha,
I don't quite see the role of the "Active-Flow-Req TLV" since it = is=20 always present in all "Request" messages from NAS and doe snot convey = actual=20 information. I am guessing this may have been included to distinguish = the=20 Request from the Response, but I think this can be easily inferred=20 by the direction NAS-->AN vs AN-->NAS.
Somewhat similar to what is already done for the Delegated = Bandwidth=20 Query Request/Response of ancp-mc-extensions-01.
Is this TLV really needed?

Thanks 

Francois



Begin forwarded message:

From: "BOCCI Matthew" <Matthew.Bocci@alcatel-lu= cent.com>
Date: 31 March 2009 17:51:37 CEDT
To: "Aniruddha A (anira)" <anira@cisco.com>, <ancp@ietf.org>
Subject: Re: [ANCP] ANCP messages for = Multicast query and=20 report

This was discussed in San Francisco, and there seemed to be = agreement=20 in
principle, but we would appreciate feedback on this proposal = on the=20 list
from the WG.

Matthew


-----Original = Message-----
From: ancp-bounces@ietf.org = [mailto:ancp-bounces@ietf.org] = On=20
Behalf Of Aniruddha A = (anira)
Sent: 06 March 2009 = 11:00
To: ancp@ietf.org
Subject: Re: [ANCP] ANCP messages for = Multicast=20 query and report



Hi All,

I propose the following new ANCP message = to get=20 all ports on
AN for a given Multicast flow (S,G)=20 :

- Request message from NAS to AN to get = all the=20 ports where a
multicast
 flow is active.
 The Mandatory Active-Flow-Req TLV = is=20 followed by the Flow-ID TLV
 which identifies which flow we are = interested in.

     0 1 2 3 4 = 5 6 7 8=20 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20        Type (0x88-0C)=20         |=20 =           Length=20 =             &= nbsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Vers  | =  Sub=20  |MsgType=3D0x92   | Res   |=20        Code=20 =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Partition ID =  |=20 =            Transac= tion=20 Identifier=20 =             |=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |I|=20      SubMessage Number=20      |=20 =           Length=20 =             &= nbsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20     ActiveFlowReq TLV =3D0x103  |=20    ActiveFlow-Length=20 =          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Mcast = Flow ID=20 TLV =3D 0x107    |S|   Mcast Flow = ID-Length=20      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily=20    | EncType =       |=20  Mcast source=20 =             &= nbsp;   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily=20    | EncType =       |=20  Mcast group=20 =             &= nbsp;    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- Report message from AN to NAS to send = all the=20 ports for a
particular flow.
 The report uses a new TLV - 0x108=20

     0 1 2 3 4 = 5 6 7 8=20 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20        Type (0x88-0C)=20         |=20 =           Length=20 =             &= nbsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Vers  | =  Sub=20  |MsgType=3D0x92    | Res   |=20        Code=20 =          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Partition ID =  |=20 =            Transac= tion=20 Identifier=20 =             |=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |I|=20      SubMessage Number=20      |=20 =           Length=20 =             &= nbsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |ActiveFlow = Target Ports=20 =3D 0x108|    ActiveFlow-Length=20 =          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Mcast = Flow ID=20 TLV =3D 0x107    |S|   Mcast Flow = ID-Length=20      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily=20    | EncType =       |=20  Mcast source=20 =             &= nbsp;   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily=20    | EncType =       |=20  Mcast group=20 =             &= nbsp;    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Followed by one or more Target-Type TLV = which=20 identifies the port

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20     Target-type-TLV=3D0x1000 =    |=20   Target-TLV-Length=20 =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20 =            ID=20 type =            |=20   Circuit ID Length=20 =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20 =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
    ~=20 =             &= nbsp;           &n= bsp;  Client-ID=20 =             &= nbsp;           &n= bsp;~
    |=20 =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


--
Regards,
Aniruddha. A

-----Original = Message-----
From: Maglione Roberta [mailto:roberta.maglione= @telecomitalia.it]
Sent: Thursday, February 05, 2009 9:19=20 PM
To: Aniruddha A (anira); ancp@ietf.org
Subject: RE: ANCP messages for Multicast = query=20 and report

Hi Aniruddha,
       your=20 proposal seems interesting to me, but I have a = comment:
section 3.4.3 of the ancp-framework = draft=20 defines 3 different
types of reporting = function:
- report for one Access = Port;
- report for one multicast = flow;
- a global report for one Access=20 Node.

If my understanding is correct, your = proposal=20 addresses 1 and
3, do you plan to extend it to cover = also case=20 2?

Thanks and best = regards.
Roberta

-----Original = Message-----
From: ancp-bounces@ietf.org = [mailto:ancp-bounces@ietf.org] = On=20
Behalf Of Aniruddha A = (anira)
Sent: Monday, January 12, 2009 6:46=20 PM
To: ancp@ietf.org
Subject: [ANCP] ANCP messages for = Multicast=20 query and report

Hi all,

In the ANCP multicast extensions, there = has to=20 be a way For
the NAS to query the AN for the state of = active=20 multicast flows on it.

We propose the following 2 new messages = for this=20 purpose:
-  Active-Flow = Request
-  Active-Flow = Report

The query from the NAS can be for all = flows on=20 the AN or
flows active on a single port. Message = Type 0x92=20 is used.

Description and message = formats:

 Active-Flow Request = Message

  The Active Flow Request = message is=20 sent by the NAS to the AN to
  request multicast flow = status on the=20 AN.  The payload contains the
  following = TLVs:

  o  The Active-Flow-Req = TLV=20 (0x103)
     A = Mandatory=20 TLV.

  o  The Target Type=20 TLV.
     Optional = TLV, if=20 present, request is for a single port.

  On receiving the Active Flow = Request=20 message, the AN MUST respond
  with the Active Flow Report=20 containing the requested information if
  the Multicast capability has = been=20 negotiated.  The format of the
  message is shown=20 below:

     0 1 2 3 4 = 5 6 7 8=20 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20        Type (0x88-0C)=20         |=20 =           Length=20 =             &= nbsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Vers  | =  Sub=20  |MsgType=3D0x92   | Res   |=20        Code=20 =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Partition ID =  |=20 =            Transac= tion=20 Identifier=20 =             |=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |I|=20      SubMessage Number=20      |=20 =           Length=20 =             &= nbsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20     ActiveFlowReq TLV =3D0x103  |=20    ActiveFlow-Length=20 =          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20     Target-type-TLV=3D0x1000 =    |=20   Target-TLV-Length=20 =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20 =            ID=20 type =            |=20   Circuit ID Length=20 =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20 =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
    ~=20 =             &= nbsp;           &n= bsp;  Client-ID=20 =             &= nbsp;           &n= bsp;~
    |=20 =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          = ;            =           Figure=20 1

 Active-Flow Report = Message

  The Active Flow Report = message is=20 sent from the AN to the NAS in
  response to the Active Flow = Request=20 message.  Active Flow Report
  message contains information = on the=20 requested multicast flows.  The
  report can be for a single = port, or=20 all ports depending on
the Target
  Type in the = request.

  o Single Port = Report

  If the Active Flow Request = had a=20 specific port (the presence of a
  Target Type TLV), the = response has=20 the following format:

     0 1 2 3 4 = 5 6 7 8=20 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20        Type (0x88-0C)=20         |=20 =           Length=20 =             &= nbsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Vers  | =  Sub=20  |MsgType=3D0x92    | Res   |=20        Code=20 =          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Partition ID =  |=20 =            Transac= tion=20 Identifier=20 =             |=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |I|=20      SubMessage Number=20      |=20 =           Length=20 =             &= nbsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | = ActiveFlowPortEntryTLV=20 =3D0x105 |    ActiveFlow-Length=20 =          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20     Target-type-TLV=3D0x1000 =    |=20   Target-TLV-Length=20 =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20 =            ID=20 type =            |=20   Circuit ID Length=20 =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20 =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
    ~=20 =             &= nbsp;           &n= bsp;  Client-ID=20 =             &= nbsp;           &n= bsp;~
    |=20 =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          = ;            =           Figure=20 2

  Followed by the Multicast = Flow ID=20 TLVs (0x107), one for
each flow on
  the port.  The format = of the=20 Flow ID TLV is:

     0 1 2 3 4 = 5 6 7 8=20 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Mcast = Flow ID=20 TLV =3D 0x107    |S|  Mcast Flow ID-Length=20       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily=20    | EncType =       |=20  Mcast source=20 =             &= nbsp;   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily=20    | EncType =       |=20  Mcast group=20 =             &= nbsp;    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          = ;            =           Figure=20 3

  S is the source flag, if = set,=20 multicast source address MUST be
  present = (SSM).

 o  Report for all=20 ports

  If the Active Flow Request = did not=20 specify a specific port
(no Target
  Type TLV), the response will = have=20 the following format:

     0 1 2 3 4 = 5 6 7 8=20 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |=20        Type (0x88-0C)=20         |=20 =           Length=20 =             &= nbsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Vers  | =  Sub=20  |MsgType=3D0x92   | Res   |=20        Code=20 =           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Partition ID =  |=20 =            Transac= tion=20 Identifier=20 =             |=
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |I|=20      SubMessage Number=20      |=20 =           Length=20 =             &= nbsp;|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |ActiveFlowMcastEntryTLV=20 =3D0x104 |    ActiveFlow-Length=20 =          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Mcast = Flow ID=20 TLV =3D 0x107    |S|   Mcast Flow = ID-Length=20      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily=20    | EncType =       |=20  Mcast source=20 =             &= nbsp;   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AddrFamily=20    | EncType =       |=20  Mcast group=20 =             &= nbsp;    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          = ;            =           Figure=20 4

  Followed by the Target Type=20 TLV.

  A Multicast Entry TLV = (0x104)=20 determines the (flow, port),
therefore
  it will have a Flow ID TLV = and a=20 Target-Type TLV as its
sub TLVs, and
  there will be as many = Multicast=20 Entry TLVs as the number
of flows on
  the AN.

We have an implementation running with = these=20 message types.
--
Regards,
Aniruddha. A
_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www.ietf.org/= mailman/listinfo/ancp

Questo messaggio e i suoi allegati sono=20 indirizzati
esclusivamente alle persone indicate. La = diffusione, copia o
qualsiasi altra azione derivante dalla=20 conoscenza di queste
informazioni sono rigorosamente vietate. = Qualora=20 abbiate
ricevuto questo documento per errore = siete=20 cortesemente
pregati di darne immediata comunicazione = al=20 mittente e di
provvedere alla sua distruzione,=20 Grazie.

This e-mail and any attachments is = confidential=20 and may
contain privileged information intended = for the=20 addressee(s) only.
Dissemination, copying, printing or use = by=20 anybody else is
unauthorised.
If you are not the intended recipient, = please=20 delete this
message and any attachments and advise = the=20 sender by return
e-mail, Thanks.

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www.ietf.org/= mailman/listinfo/ancp

__________________________________________= _____
ANCP=20 mailing list
ANCP@ietf.org
https://www.ietf.org/= mailman/listinfo/ancp



------_=_NextPart_001_01C9F5BC.E5B7D7E7-- From sob@harvard.edu Mon Jun 29 06:35:50 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48A7B28C227; Mon, 29 Jun 2009 06:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xGgrRRYRWsu; Mon, 29 Jun 2009 06:35:49 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id EE6A33A6AB2; Mon, 29 Jun 2009 06:35:48 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 8D9DF1938B8C; Mon, 29 Jun 2009 09:35:36 -0400 (EDT) To: tsv-dir@ietf.org Message-Id: <20090629133536.8D9DF1938B8C@newdev.eecs.harvard.edu> Date: Mon, 29 Jun 2009 09:35:36 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) X-Mailman-Approved-At: Mon, 29 Jun 2009 06:38:54 -0700 Cc: sven.ooghe@alcatel-lucent.com, ancp@ietf.org, michel.platnic@ecitele.com Subject: [ANCP] TSV review of draft-ietf-ancp-framework-10.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 13:35:50 -0000 TSV-dir review of draft-ietf-ancp-framework-10.txt I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. The primary transport-related issue I see with the document is its some naive assumption that simple prioritization will mean that the control protocol will not experience congestion. (See, for example section 2.3) I would suggest that the document say that use of a IETF approved congestion aware reliable transport protocol (e.g., TCP or SCTP) be required for the control protocol wherever the control protocol is transported on IP. (Section 4.5) The abstract says that the purpose of the document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)). But the document is more than a framework document. As indicated by the title, the document also includes a set of requirements for an Access Node Control Mechanism. The document also includes a set of functional requirements for devices involved in such a system. It seems to me that the document is trying to do too much. I find that the framework presented in this document to be complex and, too often, vague. I also find many of the requirements to be incomplete. a few examples - this is not an exhaustive list I note that there is a mixture of "MUST" and "must" - that could be confusing - since this is supposed to be framework & requirements documents it may be reasonable to not use RFC 2119 termonology section 4.1 - "The ANCP MUST address all use cases described in this document" - there are many use cases in the document - it seems to me that requiring support for all use cases is not needed for interoperability and limits a vendor's ability to design a product for a specific need. (See RFC 2119 section 6) "The ANCP MUST be flexible enough to accommodate the various technologies that can be used in an access network and in the Access Node." if this means Ethernet & ATM say so - if it means more - say so . "The Access Node Control interactions MUST be reliable (using either a reliable transport protocol (e.g. TCP) for the Access Node Control Protocol messages, or by designing ANCP to be reliable)." - see above, I do not think that the time it would take to make the ANCP a reliable (and congestion responsive) protocol is nearly worth the effort. "The ANCP MUST allow fast-paced transactions, in order to provide real time transactions between a NAS and a fully populated Access Node." - without a definition of "fast-paced" this is an impossible requirement to meet "The ANCP SHOULD support a means to handle sending/receiving a large burst of messages efficiently." - see previous comment section 4.2 "In case of Admission Control without AN Bandwidth Delegation, the ANCP must allow the NAS to reply to a query from the AN indicating whether or not a multicast flow may be replicated to a particular Access Port." - is this saying that it has permission or that this just could happen? "In case of Admission Control with AN Bandwidth Delegation, the ANCP must allow the NAS to delegate a certain amount of bandwidth to the AN for a given Access Port for multicast services only." - "delegate " or "dedicate"? "In case of Admission Control with AN Bandwidth Delegation, the ANCP must allow the AN to autonomous release redundant multicast bandwidth on a given Access Port." - meaning that the protocol must include a way for the AN to say that it did this? - otherwise not sure how the requirement applies to the control protocol. - e.g. sections 4.6 and 4.7 are mixtures of protocol requirements and device requirements section 4.3 "The ANCP MUST be simple and lightweight enough to allow an implementation on Access Nodes with limited control plane resources (e.g. CPU and memory)." - see previous two comments section 4.4 - Access Node Control Adjacency Requirements please be specific as to what this section is talking about - DSLAMs figuring out that ANs exist? adjacent DSLAMs? adjacent control systems? in same provider or different providers? section 4.6.1 - I did not understand the 1st paragraph in section 4.6.1 section 4.6.2 - "The Access Node must process control transactions in real-time." - what does this mean? a specific data rate? a specific response latency? "The Access Node should mark Access Node Control Protocol messages with a high priority (e.g. VBR-rt for ATM cells, p-bit 6 or 7 for Ethernet packets) in order for the packets not to be dropped in case of congestion." - see 1st comment - this is a naive assumption section 4.6.5 2nd pp - sentence is not quite English and needs references for PPPoE and DHCP messages section 4.7.1 "The NAS must support learning of access loop attributes (e.g. net data rate), from its peer Access Node partitions via the Access Node Control Mechanism." - this is one way to phrase this but it seems to me that "learning" is not the right concept - it may be better to say that the access loop attributes used by the NAS are configured by the ANCP - this applies in a number of other cases "The NAS must correlate Access Node Control information with the RADIUS authorization process and related subscriber data." - I have no idea what this means "The NAS should support shaping traffic directed towards a particular access loop to include layer-1 and layer-2 encapsulation overhead information received for a specific access loop from the AN via the Access Node Control Mechanism." - no do I understand what this means there are many other requirements in this document that I find to be vague or incomplete - the above are just some examples Scott From wdec@cisco.com Tue Jun 30 04:45:10 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14EC28C38A for ; Tue, 30 Jun 2009 04:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[AWL=1.396, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8KTWmneid2a for ; Tue, 30 Jun 2009 04:45:08 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0C1303A6936 for ; Tue, 30 Jun 2009 04:45:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,316,1243814400"; d="scan'208,217";a="43991742" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Jun 2009 11:44:28 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5UBiSjY028047; Tue, 30 Jun 2009 13:44:28 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5UBiSxJ023246; Tue, 30 Jun 2009 11:44:28 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jun 2009 13:44:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F978.1FC97999" Date: Tue, 30 Jun 2009 13:44:25 +0200 Message-ID: In-Reply-To: <71304EF1-AAAA-4425-8096-0FC16CF39E8C@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status-Info Result Code Registry Re: [ANCP] Splitting multicast from protocol doc Thread-Index: Acn0GjJcd1iu+vieT7mElRsNYPkYcwFXby0Q References: <0458D2EE0C36744BABB36BE37805C29A039300AF@FRVELSMBS11.ad2.ad.alcatel.com> <671A5BF3-6386-4741-84C2-5B3051D77DAA@cisco.com> <0458D2EE0C36744BABB36BE37805C29A03EC4066@FRVELSMBS11.ad2.ad.alcatel.com> <282BBE8A501E1F4DA9C775F964BB21FE3E60EF3566@GRFMBX704BA020.griffon.local> <5DAF167E-64F2-4CD6-A230-709B0920CC1C@cisco.com> <71304EF1-AAAA-4425-8096-0FC16CF39E8C@cisco.com> From: "Wojciech Dec (wdec)" To: "Francois Le Faucheur (flefauch)" , "Maglione Roberta" , "Sanjay Wadhwa" X-OriginalArrivalTime: 30 Jun 2009 11:44:28.0598 (UTC) FILETIME=[200E7560:01C9F978] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=57303; t=1246362268; x=1247226268; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20Status-Info=20Result=20Code=20Registry= 20=20Re=3A=20[ANCP]=20Splitting=20multicast=20from=20protoco l=20doc |Sender:=20; bh=/Cn5kylLZp3fMR5JGCn6dBrn4KoW+dUNOOZt2+LyHtA=; b=m6jgDUtBE9+OmpxgqNwDtlU+sVVVkSEkzdsKRZdNi+PxblTWiRphFTqlNj 00cGFLbDIgVP6916OkBQn1Lzco9jSG5lIuMc5zTfk/pgfBMrw8ldi4vyDse6 s/6FI32pxr; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ancp@ietf.org Subject: Re: [ANCP] Status-Info Result Code Registry Re: Splitting multicast from protocol doc X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 11:45:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9F978.1FC97999 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 in the updated drafts could the editors please include in the IANA = section also the proposed allocation strategy (assuming that future = assignments will be made by IANA)? =20 Thanks, Woj. ________________________________ From: Francois Le Faucheur (flefauch)=20 Sent: 23 June 2009 17:49 To: Maglione Roberta; Sanjay Wadhwa Cc: Wojciech Dec (wdec); BOCCI Matthew; tom.taylor@rogers.com Taylor; = ancp@ietf.org; Francois Le Faucheur (flefauch) Subject: Status-Info Result Code Registry Re: [ANCP] Splitting = multicast from protocol doc =09 =09 Roberta, Sanjay, We agreed that : (i) the Well-Known TLV specification (eg equivalent of 5.4.5.1.3 of = ancp-proto) would remain in ancp-proto (as a Well-Known TLV) (ii) the use and encoding of theses TLV by Multicast messages (eg = equivalent of 5.4.5.3 in ancp-proto) would go into the multicast I-D.=20 =09 Now, the Well-Known TLVs seem to have an encoding that depends on the = actual ANCP message using the TLV.=20 For example, for the Status TLV, ancp-proto says: " Result Code: Conveys the result code for the command or message, as defined by the application. " Similarly, for the Command TLV, ancp-proto says: " Command-Info: Command information as defined for each message type. The field can consist of sub-TLVs. " My assumption is that: * there is a single shared registry for "Result Codes" for the = Status-Info TLV (which will contain the reunion of all the values = defined by the multiple message types that can use the TLV).=20 * there is a single shared registry for "Command Code" of the Command = TLV (which will contain the reunion of all the values defined by the = multiple message types that can use the TLV).=20 Therefore, I assume that : * ancp-proto will define (in IANA section) the single Result Code = registry for Status-Info TLV but will not allocate values * multicast I-D will allocate Result Code values * ancp-proto will define (in IANA section) the single Command Code = registry for Command TLV but will not allocate values * multicast I-D will allocate Command Code values Please let me know if this is not the right approach. Thanks Francois On 17 Jun 2009, at 16:20, Francois Le Faucheur IMAP wrote: Folks,=20 Sanjay, Roberta and I had a first chat. Our proposal is in line with = the thread below with a few more specifics described below:=20 =09 =09 =09 Regarding the ANCP base header: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D I think what Woj is proposing is that: * ancp-proto: - keeps a small section that introduce the notion that some ANCP = message may be ANCP-specific non-GSMP message types ancp-proto will include a section on "generic ANCP protocol mechanisms = for other uses cases". This will discuss: * alternate semantics for Transaction ID (as used by macst use case) =09 * notion of using different Message Types for a Response and the = Request it is responding to (as used by mcast use case) =09 * Well-Known TLVs (Target, Command, Status-Info) =09 ancp-mcast will refer to the above section of ancp-proto when defining = the mcast specific messages/extensions. text from current section 5.4.5.2 and 5.4.5.3 (ie actual mcast = messages) will move to ancp-mcast. text from current section 4.4 (ie description of mcast use case) will = move to ancp-mcast (and be expanded to cover the other mcast use cases = than transactional mcast). =09 - defines the based header for such messages (ie what is currently = at the beginning of 5.4.5 )=20 * ancp-multicast: - refers to ancp-proto for the definition of ANCP base header =09 - defines multicats messages using this ANCP base header =09 Is that right Woj?=20 =20 Woj> Yes, that's it, noting that if people see a better way to = cut-it-up, then please do come forward with your opinions. One other thing to consider adding to the ancp-multicast draft is = of course the capability extension code point(s), with the capability = extension mechanism (negotiation?) defined in the ancp-protocol draft. =20 That would work for me & Roberta. Is this OK to all? Regarding Provisioning =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We could move the definition of the Provisioning message into = ancp-proto. ancp-mcast woudl then define the TLVs that are relevant for = provisioning of multicast and that woudl be carried inside the = Provisioning message defined in ancp-proto. Note that there is currently no TLVs defined for teh provisioning of = non-multicast things. So even if the Provisioning message is defined = inside ancp-proto it wouldn't, for now, be of real use for ancp-proto. = But still that seems like the right place to define the message itself. text for definition of Provisioning message in ancp-mcast will move to = ancp-proto. We'll make sure it is clear that Provisioning message is not = intended to superseed Port Management message (for per-line config). Please do let us know if you have comments/concerns with this = proposal. Francois Is this OK to all?=20 =20 Woj> Works for me. =20 Regards, Woj.=20 Francois PS: in line with Woj suggestion, i sent an invite for editors of the = two docs to discuss. On 11 Jun 2009, at 11:49, Maglione Roberta wrote: =09 Hi Woj, I'm not sure I've fully understood your proposal about = splitting the work between the two documents: =09 > - ANCP base header definitions, extensions -> ancp-protocol =3D =3D> in my understanding this is the text from section 5.4.5, = isn't it? However if we move the multicast messages and the error codes in = the other draft why should we leave in the base protocol the ANCP base = header definition? The ANCP message format defined in section 5.4.5 is = currently used only for Multicast messages (mcast replication control = message and mcast status message) thus if we move these messages out of = base protocol drafts shouldn't we move also the ANCP base header = specification? The only reason I thought about is because when we defined = multicast messages we introduced a new approach/logic for message = semantic: instead of re-using the same message for request and response = with different result code we used two different messages for request = and response and we added the result code =3D0 (ignore) semantic. Is the = specification of this behavior that you are suggesting to keep in the = base protocol draft in order to have this approach available in future = for other messages definitions? =20 =09 >- Mcast capability negotiation, messages, message flows, error = codes -> mcast ID =09 Thanks, Regards Roberta =09 ________________________________ From: BOCCI Matthew [mailto:Matthew.Bocci@alcatel-lucent.com]=20 Sent: Tuesday, June 09, 2009 7:35 AM To: Wojciech Dec (wdec); Francois Le Faucheur (flefauch); Maglione = Roberta Cc: ancp@ietf.org Subject: RE: [ANCP] Splitting multicast from protocol doc =09 I only actually saw one against for splitting the mcast text from = the ANCP protocol spec. However, I accept that it may not be that easy = to split it out. =09 I am fine with the approach below, so long as the ANCP base = protocol spec can stand alone and that it is not necessary to implement = the mcast spec to support the base mcast functions in the ANCP protocol = spec. =09 Matthew =09 =09 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: 08 June 2009 12:19 To: Francois Le Faucheur (flefauch); BOCCI Matthew; Maglione = Roberta Cc: ancp@ietf.org Subject: RE: [ANCP] Splitting multicast from protocol doc =09 Hi Francois, =09 let's go with the this approach. Some delicate surgery is needed on = the ancp-protocol draft to move the mcast specific parts to the new ID, = but leave the base protocol parts that have been defined (or re-defined) = as part of the mcast work in the base protocol spec. A rough line to = draw would be: - ANCP base header definitions, extensions -> ancp-protocol - Mcast capability negotiation, messages, message flows, error = codes -> mcast ID There are some provisioning aspects of the mcast use-cases (eg the = lists) that likely could apply to the wider provisioning use-case, so = this could go either way. =09 It would seem like having the editors of both docs discuss the what = goes where would be a good next step. =09 Regards, Woj. =09 =09 ________________________________ From: Francois Le Faucheur (flefauch)=20 Sent: 08 June 2009 12:39 To: BOCCI Matthew; Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: Re: [ANCP] Splitting multicast from protocol doc Matthew, Woj, =09 We had a few responses to this proposal. What is the final = decision? =09 Thanks =09 Francois =09 On 31 Mar 2009, at 22:21, Francois Le Faucheur IMAP wrote: =09 support. Francois =09 On 31 Mar 2009, at 17:46, BOCCI Matthew wrote: =09 There was a proposal at the last IETF to take the multicast text = from draft-ietf-ancp-protocol-05 and merge it with = draft-lefaucheur-ancp-mc-extensions-01. We would thus have two protocol drafts: draft-ietf-ancp-protocol : Containing the solutions for the = Topology discovery, line configuration and OAM use cases=20 Multicast extensions draft: Containing the transactional multicast = solution and all of the content of draft-lefaucheur This would allow us to move forward with WG LC on the basic use = case solutions, and also keep all of the multicast extensions in a = single draft. Please can you indicate to the list whether you support this = proposal. Regards Matthew =09 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp =09 =09 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. Rispetta l'ambiente. Non stampare questa mail = se non =E8 necessario.=20 ------_=_NextPart_001_01C9F978.1FC97999 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
in the updated drafts could the editors please include in the = IANA=20 section also the proposed allocation strategy (assuming that future = assignments=20 will be made by IANA)?
 
Thanks,
Woj.

From: Francois Le Faucheur = (flefauch)=20
Sent: 23 June 2009 17:49
To: Maglione Roberta; = Sanjay=20 Wadhwa
Cc: Wojciech Dec (wdec); BOCCI Matthew; = tom.taylor@rogers.com=20 Taylor; ancp@ietf.org; Francois Le Faucheur = (flefauch)
Subject:=20 Status-Info Result Code Registry Re: [ANCP] Splitting multicast from = protocol=20 doc

Roberta, Sanjay,

We agreed that :
(i) the=20 Well-Known TLV specification (eg equivalent of 5.4.5.1.3 of = ancp-proto) would=20 remain in ancp-proto (as a Well-Known TLV)
(ii) the use=20 and encoding of theses TLV by Multicast messages (eg equivalent of = 5.4.5.3 in=20 ancp-proto) would go into the multicast I-D. 

Now, the Well-Known TLVs seem to have an encoding that depends on = the=20 actual ANCP message using the TLV. 
For example, for the Status TLV, ancp-proto says:
"   Result Code:
             Conveys the = result code=20 for the command or message, as
             defined by the=20 application.
"
Similarly, for the Command TLV, ancp-proto says:
"   Command-Info:
             Command = information as=20 defined for each message type.  The
             field can consist = of=20 sub-TLVs.
"

My assumption is that:
* there is a single shared registry for "Result Codes" for = the=20 Status-Info TLV (which will contain the reunion of all the = values=20 defined by the multiple message types that can use the=20 TLV). 
* there is a single shared registry for "Command Code" =  of the=20 Command TLV (which will contain the reunion of all the = values=20 defined by the multiple message types that can use the=20 TLV). 

Therefore, I assume that :
* ancp-proto will = define (in IANA=20 section) the single Result Code registry for Status-Info TLV but = will not=20 allocate values
* = multicast=20 I-D will allocate Result Code values
* ancp-proto will = define (in IANA=20 section) the single Command Code registry for Command TLV but = will not=20 allocate values
* = multicast=20 I-D will allocate Command Code values

Please let me know if this is not the right approach.


Thanks

Francois




On 17 Jun 2009, at 16:20, Francois Le Faucheur IMAP = wrote:
Folks,

Sanjay, Roberta and I had a first chat. Our proposal is in line = with=20 the thread below with a few more specifics described = below: 



Regarding the ANCP base header:
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
I think what Woj is proposing is that:
*=20 ancp-proto:
- keeps a small section = that=20 introduce the notion that some ANCP message may be ANCP-specific = non-GSMP message types
ancp-proto will include a section on "generic ANCP protocol = mechanisms=20 for other uses cases". This will discuss:
* alternate=20 semantics for Transaction ID (as used by macst use case)
* notion of=20 using different Message Types for a Response and the Request it is=20 responding to (as used by mcast use case)
* Well-Known=20 TLVs (Target, Command, Status-Info)

ancp-mcast will refer to the above section of ancp-proto when = defining=20 the mcast specific messages/extensions.

text from current section 5.4.5.2 and 5.4.5.3 (ie actual mcast=20 messages) will move to ancp-mcast.

text from current section 4.4 (ie description of = mcast use=20 case) will move to ancp-mcast (and be expanded to = cover the other=20 mcast use cases than transactional mcast).

- defines the based = header for such=20 messages (ie what is currently at the beginning of = 5.4.5=20 ) 
*=20 ancp-multicast:
- refers=20 to ancp-proto for the definition of ANCP base header
-=20 defines multicats messages using this ANCP base header
Is that right Woj? 
 
Woj> Yes,=20 that's it, noting that if people see a better way to cut-it-up, = then=20 please do come forward with your opinions.
One other=20 thing to  consider adding to the ancp-multicast draft is of = course=20 the capability extension code point(s), with the capability = extension=20 mechanism (negotiation?) defined in the ancp-protocol=20 draft.
 
That would work for me & Roberta. Is this OK = to=20 all?


Regarding Provisioning
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
We could move the definition of the Provisioning message = into=20 ancp-proto. ancp-mcast woudl then define the TLVs that are = relevant for=20 provisioning of multicast and that woudl be carried inside the=20 Provisioning message defined in ancp-proto.
Note that there is currently no TLVs defined for teh = provisioning=20 of non-multicast things. So even if the Provisioning message is = defined=20 inside ancp-proto it wouldn't, for now, be of real use for = ancp-proto.=20 But still that seems like the right place to define = the=20 message itself.

text for definition of Provisioning message in ancp-mcast will = move to=20 ancp-proto. We'll make sure it is clear that Provisioning message is = not=20 intended to superseed Port Management message (for per-line = config).

Please do let us know if you have comments/concerns with this=20 proposal.

Francois

Is this OK to all? 
 
Woj> Works for me.
 
Regards,
Woj. 

Francois

PS: in line with Woj suggestion, i sent an invite for = editors of=20 the two docs to discuss.

On 11 Jun 2009, at 11:49, Maglione Roberta wrote:
Hi=20 Woj,
    =20 I=92m not sure I=92ve fully understood your proposal about = splitting the=20 work between the two documents:
> - ANCP base = header=20 definitions, extensions ->=20 ancp-protocol
=3D =3D> in my = understanding this is the text from section 5.4.5, = isn=92t=20 it? However if we=20 move the multicast messages and the error codes in the other = draft why=20 should we leave in the base protocol the ANCP base header = definition?=20 The ANCP message format defined in section 5.4.5 is currently = used=20 only for Multicast messages (mcast replication control message = and=20 mcast status message) thus if we move these messages out of = base=20 protocol drafts shouldn=92t we move also the ANCP base header=20 specification? The = only=20 reason I thought about is because when we defined multicast = messages=20 we introduced a new approach/logic for message semantic: = instead of=20 re-using the same message for request and response with = different=20 result code we used two different messages for request and = response=20 and we added the result code =3D0 (ignore) semantic. Is the=20 specification of this behavior that you are suggesting to keep = in the=20 base protocol draft in order to have this approach available = in future=20 for other messages definitions? =   >- Mcast = capability=20 negotiation, messages, message flows, error codes -> = mcast=20 ID Thanks, Regards Roberta
From: BOCCI Matthew [mailto:Matthew.Bocci@alc= atel-lucent.com] 
Sent: Tuesday, June 09, = 2009 7:35=20 AM
To: Wojciech Dec = (wdec); Francois=20 Le Faucheur (flefauch); Maglione Roberta
Cc: ancp@ietf.org
Subject: RE: [ANCP] = Splitting=20 multicast from protocol doc
I = only=20 actually saw one against for splitting the mcast text from the = ANCP=20 protocol spec. However, I accept that it may not be that easy = to split=20 it out. I = am fine=20 with the approach below, so long as the ANCP base protocol = spec can=20 stand alone and that it is not necessary to implement the = mcast spec=20 to support the base mcast functions in the ANCP protocol=20 spec. Matthew
From: Wojciech Dec (wdec) = [mailto:wdec@cisco.com] 
Sent: 08 June 2009=20 12:19
To: Francois Le = Faucheur=20 (flefauch); BOCCI Matthew; Maglione = Roberta
Cc: ancp@ietf.org
Subject: RE: [ANCP] = Splitting=20 multicast from protocol doc
Hi=20 Francois, let's go with = the this=20 approach. Some delicate surgery is needed on the ancp-protocol = draft=20 to move the mcast specific parts to the new ID, but leave the = base=20 protocol parts that have been defined (or re-defined) as = part of=20 the mcast work in the base protocol spec. A rough line to draw = would=20 be: - ANCP base = header=20 definitions, extensions -> = ancp-protocol - Mcast = capability=20 negotiation, messages, message flows, error codes -> = mcast=20 ID There are some=20 provisioning aspects of the mcast use-cases (eg the lists) = that likely=20 could apply to the wider provisioning use-case, so this could = go=20 either way. It would seem = like having=20 the editors of both docs discuss the what goes where = would be a=20 good next step. Regards, Woj.
From: Francois Le = Faucheur=20 (flefauch) 
Sent: 08 June 2009=20 12:39
To: BOCCI Matthew; Wojciech Dec=20 (wdec)
Cc: ancp@ietf.org
Subject: Re: [ANCP] = Splitting=20 multicast from protocol doc Matthew, = Woj,
We had a few responses to this = proposal.=20 What is the final = decision?
Thanks
Francois
On 31 Mar 2009, at 22:21, Francois = Le=20 Faucheur IMAP wrote:
support.
Francois
On 31 Mar 2009, at 17:46, BOCCI Matthew wrote:
There was a = proposal at=20 the last IETF to take the multicast text from=20 draft-ietf-ancp-protocol-05 and merge it with=20 draft-lefaucheur-ancp-mc-extensions-01.

We would thus = have two=20 protocol drafts:

draft-ietf-ancp-protocol=20 : Containing the solutions for the Topology discovery, line=20 configuration and OAM use cases 
Multicast = extensions=20 draft: Containing the transactional multicast solution and = all of=20 the content of draft-lefaucheur

This would = allow us to=20 move forward with WG LC on the basic use case solutions, and = also=20 keep all of the multicast extensions in a single=20 draft.

Please can you = indicate=20 to the list whether you support this = proposal.

Regards

Matthew

_______________________________________________
ANCP=20 mailing list
ANCP@ietf.org
https://www.ietf.org/= mailman/listinfo/ancp
Questo = messaggio=20 e i suoi allegati sono indirizzati esclusivamente alle = persone=20 indicate. La diffusione, copia o qualsiasi altra azione=20 derivante dalla conoscenza di queste informazioni sono=20 rigorosamente vietate. Qualora abbiate ricevuto questo = documento=20 per errore siete cortesemente pregati di darne immediata = comunicazione al mittente e di provvedere alla sua = distruzione,=20 Grazie.
This=20 e-mail and any attachments is confidential and=20 may contain privileged information intended for the = addressee(s)=20 only. Dissemination, copying, printing or use by anybody = else is=20 unauthorised. If you are not the intended recipient, = please=20 delete this message and any attachments and advise the = sender by=20 return e-mail, Thanks.

<logo=20 Ambiente_foglia.jpg>Rispetta l'ambiente. Non = stampare=20 questa mail se non =E8 necessario.=20
&l= t;logo=20 = Ambiente_foglia.jpg>
=


------_=_NextPart_001_01C9F978.1FC97999--