Subject: Re: [ANCP] Splitting multicast from protocol doc

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 8 Jun 2009 12:39:10 +0200

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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ancp
>

---

From: Tina TSOU <[email-masked]>
Date: Mon, 08 Jun 2009 18:58:58 +0800

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:

>>> from draft-ietf-ancp-protocol-05 and merge it with draft- 
>>> lefaucheur-ancp-mc-extensions-01.
>>>

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 8 Jun 2009 13:19:09 +0200

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: [email-masked]
	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

		support. 
		Francois

			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.

			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

---

From: "BOCCI Matthew" <[email-masked]>
Date: Tue, 9 Jun 2009 07:34:43 +0200

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:[email-masked]] 
Sent: 08 June 2009 12:19
To: Francois Le Faucheur (flefauch); BOCCI Matthew; Maglione Roberta
Cc: [email-masked]
Subject: RE: [ANCP] Splitting multicast from protocol doc

Hi Francois,

Regards,

Woj.

	Matthew, Woj, 

	Thanks

	Francois

	

	support. 

	Francois

	

	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.

	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 

	Regards 

	Matthew

---

From: Maglione Roberta <[email-masked]>
Date: Thu, 11 Jun 2009 11:49:54 +0200

Hi Woj,

> - ANCP base header definitions, extensions -> ancp-protocol
= => 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 =0 (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:[email-masked]]
Sent: Tuesday, June 09, 2009 7:35 AM
To: Wojciech Dec (wdec); Francois Le Faucheur (flefauch); Maglione Roberta
Cc: [email-masked]
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

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.

Thanks

Francois

support.
Francois

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.

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
[email-masked]<mailto:[email-masked]>
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.

Rispetta l'ambiente. Non stampare questa mail se non ? necessario.

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 11 Jun 2009 15:01:07 +0200

Hello,

Just had a quick chat with Roberta.

Regarding the ANCP base header:
==========================
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
=================
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’m not sure I’ve fully understood your proposal about  
> splitting the work between the two documents:
>
> = => 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 =0 (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?
>
> 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.
>
> 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
>
> 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:
> lists) that likely could apply to the wider provisioning use-case,  
> so this could go either way.
>
> draft-ietf-ancp-protocol : Containing the solutions for the Topology  
> discovery, line configuration and OAM use cases
> 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.
>
> 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 è necessario.
>
> <logo Ambiente_foglia.jpg>

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Thu, 11 Jun 2009 15:33:56 +0200

Hi,

	From: Francois Le Faucheur (flefauch) 
	Sent: 11 June 2009 15:01
	To: BOCCI Matthew; Wojciech Dec (wdec)
	Cc: Maglione Roberta; Francois Le Faucheur (flefauch); [email-masked]; Sanjay Wadhwa
	Subject: Re: [ANCP] Splitting multicast from protocol doc

	Hello, 

	Regarding the ANCP base header:
	==========================
	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

	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.

	Regarding Provisioning
	=================
	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? 
	 
	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.

		
		Hi Woj,

		
		Thanks,
		Regards
		Roberta

		

		Matthew

		
		Hi Francois,

		
		Regards,
		Woj.

			
			
			Thanks
			
			Francois

			support.
			Francois

			Regards

			Matthew

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

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 17 Jun 2009 16:20:21 +0200

Folks,

Sanjay, Roberta and I had a first chat. Our proposal is in line with  

> Regarding the ANCP base header:
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).
> 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.
>
> 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

>> 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 =0 (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?
>> 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
>> 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.

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 23 Jun 2009 17:49:26 +0200

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

Francois

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

> ancp-proto will include a section on "generic ANCP protocol  
> mechanisms for other uses cases". This will discuss:
> ancp-mcast will refer to the above section of ancp-proto when  
> defining the mcast specific messages/extensions.
>
> 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).
>>
>> 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).
>
>>> = => in my understanding this is the text from section 5.4.5,  
>>> isn’t it?
>>> suggesting to keep in the base protocol draft in order to have  
>>> this approach available in future for other messages definitions?
>>> implement the mcast spec to support the base mcast functions in  
>>> the ANCP protocol spec.
>>> Matthew
>>> 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:
>>> It would seem like having the editors of both docs discuss the  
>>> what goes where would be a good next step.
>>> Regards,
>>> Woj.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 30 Jun 2009 13:44:25 +0200

Hi,
 
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)?
 
Thanks,
Woj.

	From: Francois Le Faucheur (flefauch) 
	Sent: 23 June 2009 17:49
	To: Maglione Roberta; Sanjay Wadhwa
	Cc: Wojciech Dec (wdec); BOCCI Matthew; [email-masked] Taylor; [email-masked]; Francois Le Faucheur (flefauch)
	Subject: Status-Info Result Code Registry Re: [ANCP] Splitting multicast from protocol doc

	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. 

	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

	Thanks

	Francois

		Folks, 

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

		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)

		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).

				
				Is that right Woj? 

				Regarding Provisioning
				=================

		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).

		Francois

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

				Francois

					
					Hi Woj,

					
					Thanks,
					Regards
					Roberta

					

					Matthew

					
					Hi Francois,

					
					Regards,
					Woj.

					
					
					Thanks
					
					Francois

					support.
					Francois

					Regards

					Matthew