Subject: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 23 Jan 2015 14:40:50 -0000

Hi,

I appreciate this discussion, but I am not seeing a specific conclusion from it.

The current I-D makes (IMHO) the Vendor-Specific Application Code unusable. I
offered three options:

1 This value is only to be used when it is known that all devices
   participating in a network have the same understanding of 
   the content of the Vendor-Specific Application Code field.
   How this knowledge is achieved is outside the scope of this
   document

2 When this value is set, the first 32 (or 48) bits of the Vendor-
  Specific Application Code field contain an Enterprise Number
  (or OUI) that defines the context in which the remainder of
  that field is interpreted.

3 Remove the option to include a Vendor-Specific Application
   Code field.

If the WG could please pick one of these and help Young to update the document.

Thanks,
Adrian

> -----Original Message-----
> From: Giovanni Martinelli (giomarti) [mailto:[email-masked]]
> Sent: 23 January 2015 13:50
> To: [email-masked]
> Cc: Leeyoung; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode
> 
> One additional comment (hoping not additional confusion).
> 
> The idea about Optical Interface Class was taken from SRLG. Good or bad is a
> plain number and you do simple operations on it.
> 
> Cheers
> G
> 
> On 22 Jan 2015, at 09:42, Giovanni Martinelli (giomarti) <[email-masked]>
> wrote:
> 
> > Hi Adrian,
> >
> > On 21 Jan 2015, at 22:55, Adrian Farrel <[email-masked]> wrote:
> >
> >> Hi,
> >>
> >> Well, you seem to have a half-way house.
> >>
> >> You have specified the existence of a thing, but not how to read it.
> >>
> >> If you wanted to make a statement that this object will only be used when
it is
> >> known that all systems in a network come from the same vendor and/or have
> the
> >> same understanding of the encoding, that might be OK (although how you
> would
> >> ascertain this might also need to be described).
> >>
> >
> > The statement is to ensure the interface compatibility without encoding all
the
> possible details and parameter that define an interface (e.g. modulation
format,
> forward error correction etc.). This was the initial solution in the draft
then
> replaced by the interface class concept.   The WSON (RWA-only) has the
> requirement is to make sure two interface are compatible. This requirement,
> imho, can be satisfy by a simple comparison which has a boolean result.
> >
> > We end up then in  the ITU application codes for the "certified" (we'll this
is my
> term not 100% sure is the best one) compatibility where proper encoding is
> provided.
> >
> >
> >> Or you could entirely remove the vendor-specific option.
> >>
> >> Or you could put in an OUI / enterprise number followed by transparent
> bytes.
> >>
> >
> > To me I'm perfectly fine with the second option.
> >
> > Cheers
> > G
> >
> >
> >> Adrian
> >>
> >>> -----Original Message-----
> >>> From: Giovanni Martinelli (giomarti) [mailto:[email-masked]]
> >>> Sent: 21 January 2015 21:22
> >>> To: [email-masked]
> >>> Cc: Leeyoung; [email-masked];
> >>> [email-masked]; [email-masked]
> >>> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode
> >>>
> >>> Specifically to the Interface class here below.
> >>>
> >>> In the initial draft merged to this one there was the usage of OUI however
(I
> >>> guess after chatting with Lou) we decided to remove any encoding when the
> >>> Interface class is not standard.
> >>> In term of semantic the protcol does not need to decode the Interface
class
> >> since
> >>> it only assess the interface compatibility if two interfaces has a class
value
> >> that
> >>> match two interfaces cann be connected.
> >>>
> >>> Having saying that I don't have strong opinion in adding the OUI or
leaving
> >> room
> >>> for maybe future public interfaces database. For sure there's a need to
leave
> >>> room for specific compatibility assesment since there optical multivendor
> >>> compatibility has been already demonstrated.
> >>>
> >>> hope this help .
> >>>
> >>> Cheers
> >>> G
> >>>
> >>>
> >>> On 21 Jan 2015, at 21:57, Adrian Farrel <[email-masked]> wrote:
> >>>
> >>>>>>
> >>>>>> Section 4.1
> >>>>>> How do I interpret a Vendor-Specific Application Code? Is there an OUI
> >>>>>> I'm missing?
> >>>>>
> >>>>> [YOUNG] Not sure if I understood this question. What is "OUI"?
> >>>>
> >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier
> >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-
> >>> numbers.xhtml#ieee-802
> >>>> -numbers-2
> >>>>
> >>>> Or perhaps an Enterprise Number
> >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise-
> numbers
> >>>>
> >>>> The question is:
> >>>>
> >>>> You have sections 4.1.1 through 4.1.4 to tell me how to interpret the
> >> Optical
> >>>> Interface Class field when it contains an ITU-T Application Mapping.
> >>>> When I received s=0 and OI=1 it means that the Optical Interface Class
> >> contains
> >>>> a "Vendor Specific Optical Interface Class".
> >>>> How do I interpret that Optical Interface Class?
> >>>> Which vendor does it apply to?
> >>>> Is there some information elsewhere that gives me a clue as to which
> vendor
> >>> has
> >>>> encoded the information?
> >>>> Or is the information supposed to be encoded in the Optical Interface
Class,
> >>>> perhaps as the first 48 bits?
> >>>> Or am I supposed to know by context?
> >>
> >

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Fri, 23 Jan 2015 16:02:50 +0000

Dear all,

For your information. In the last SG15 meeting, Q14/15 agreed to update G.874.1 to amend the specification of ApplicationIdentifier with the following additional text:

If the ApplicationIdentifierType is STANDARD, the value of PrintableString represents a standard application code as defined in the ITU-T Recommendations. If the ApplicationIdentifierType is PROPRIETARY, the first six characters of the PrintableString must contain the Hexadecimal representation of an OUI assigned to the vendor whose implementation generated the Application Identifier; the remaining octets of the PrintableString are unspecified.

Paul Doolan had an I-D "https://tools.ietf.org/html/draft-doolan-proprietary-ac-00" to the last IETF meeting with the similar proposal.

Regards,

Kam

-----Original Message-----

From: CCAMP [mailto:[email-masked]] On Behalf Of Adrian Farrel

Sent: Friday, January 23, 2015 9:41 AM

To: 'Giovanni Martinelli (giomarti)'

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Subject: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

Hi,

The current I-D makes (IMHO) the Vendor-Specific Application Code unusable. I offered three options:

   document

   Code field.

Thanks,

Adrian

> To: [email-masked]<mailto:[email-masked]>

> Cc: Leeyoung; [email-masked]<mailto:[email-masked]>;

> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> The idea about Optical Interface Class was taken from SRLG. Good or

> bad is a plain number and you do simple operations on it.

> On 22 Jan 2015, at 09:42, Giovanni Martinelli (giomarti)

> <[email-masked]<mailto:[email-masked]>>

> > On 21 Jan 2015, at 22:55, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:

> >> If you wanted to make a statement that this object will only be

> >> used when

it is

> >> known that all systems in a network come from the same vendor

> >> and/or have

> >> same understanding of the encoding, that might be OK (although how

> >> you

> > The statement is to ensure the interface compatibility without

> > encoding all

the

> possible details and parameter that define an interface (e.g.

> modulation

format,

> forward error correction etc.). This was the initial solution in the

> draft

then

> requirement is to make sure two interface are compatible. This

> requirement, imho, can be satisfy by a simple comparison which has a boolean result.

> > We end up then in  the ITU application codes for the "certified"

> > (we'll this

is my

> term not 100% sure is the best one) compatibility where proper

> encoding is provided.

> >> Or you could put in an OUI / enterprise number followed by

> >> transparent

> >>> To: [email-masked]<mailto:[email-masked]>

> >>> Cc: Leeyoung; [email-masked]<mailto:[email-masked]>;

> >>> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> >>> In the initial draft merged to this one there was the usage of OUI

> >>> however

(I

> >>> guess after chatting with Lou) we decided to remove any encoding

> >>> when the Interface class is not standard.

> >>> In term of semantic the protcol does not need to decode the

> >>> Interface

class

> >>> it only assess the interface compatibility if two interfaces has a

value

> >>> Having saying that I don't have strong opinion in adding the OUI

> >>> or

leaving

> >>> for maybe future public interfaces database. For sure there's a

> >>> need to

leave

> >>> room for specific compatibility assesment since there optical

> >>> multivendor compatibility has been already demonstrated.

> >>> On 21 Jan 2015, at 21:57, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:

> >>>>>> How do I interpret a Vendor-Specific Application Code? Is there

> >>>>>> an OUI I'm missing?

> >>>> You have sections 4.1.1 through 4.1.4 to tell me how to interpret

> >>>> When I received s=0 and OI=1 it means that the Optical Interface

> >>>> Class

> >>>> Is there some information elsewhere that gives me a clue as to

> >>>> which

> >>>> Or is the information supposed to be encoded in the Optical

> >>>> Interface

Class,

_______________________________________________

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/ccamp

---

From: Gert Grammel <[email-masked]>
Date: Fri, 23 Jan 2015 16:49:03 +0000

Hi Kam,

Is SG15 considering to host a registry for the vendor specific application code or is the IETF registry supposed to be used?

Thanks

Gert

From: CCAMP [mailto:[email-masked]] On Behalf Of Lam, Hing-Kam (Kam)
Sent: 23 January 2015 17:03
To: [email-masked]; 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

Dear all,

Regards,

Kam

-----Original Message-----

Hi,

   document

   Code field.

Thanks,

Adrian

it is

the

format,

then

is my

(I

class

value

leaving

leave

Class,

CCAMP mailing list

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Fri, 23 Jan 2015 17:09:33 +0000

Hi Gert,

A vendor can purchase an OUI (Organizationally Unique Identifier) from the IEEE Registration Authority.
Once a vendor has its OUI, the vendor can manage its vendor-specific application identifiers under its own OUI.
SG15 doesn't need to host any registry for this purpose.

Regards,
Kam

From: Gert Grammel [mailto:[email-masked]]
Sent: Friday, January 23, 2015 11:49 AM
To: Lam, Hing-Kam (Kam); [email-masked]; 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); [email-masked]; [email-masked]; [email-masked]
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

Hi Kam,

Thanks

Gert

From: CCAMP [mailto:[email-masked]] On Behalf Of Lam, Hing-Kam (Kam)
Sent: 23 January 2015 17:03
To: [email-masked]<mailto:[email-masked]>; 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

Dear all,

Regards,

Kam

-----Original Message-----

Hi,

   document

   Code field.

Thanks,

Adrian

it is

the

format,

then

is my

(I

class

value

leaving

leave

Class,

CCAMP mailing list

---

From: Leeyoung <[email-masked]>
Date: Fri, 23 Jan 2015 17:17:35 +0000

Hi,

Thanks Adrian for taking this on. 

My preference is Option 1. It would be hard to catch moving target around this area if we were to take Option 2. 

Thanks,
Young

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Friday, January 23, 2015 8:41 AM
To: 'Giovanni Martinelli (giomarti)'
Cc: Leeyoung; [email-masked]; [email-masked]; [email-masked]
Subject: Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

Hi,

Thanks,
Adrian

it is
the
format,
then
is my
(I
class
value
leaving
leave
Class,

---

From: Lou Berger <[email-masked]>
Date: Fri, 23 Jan 2015 12:24:29 -0500

On 1/23/2015 12:17 PM, Leeyoung wrote:
> My preference is Option 1. 
Thanks Young.

My memory is that this was the intent of the WG at the time this point
was discussed. So, I also prefer/support option 1.

Lou

> It would be hard to catch moving target around this area if we were to take Option 2. 
>
> Thanks,
> Young
>
> [email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 23 Jan 2015 18:45:54 -0000

> Thanks Adrian for taking this on.

Well, we'll get there eventually!

> My preference is Option 1.

OK. 
It is my least favorite option because it is most likely to hit interoperability
issues.
So, if the WG wants to go this way, we will have to work a little to explain how
it works and why it isn't a problem (specifically for the IESG).

> area if we were to take Option 2.

I see no moving targets at all.
This is how all other vendor-specific fields are handled in protocols.
The way it works is that anyone receiving such a field looks at the first 32
bits and interprets it as an Enterprise Code from the IANA registry (hint: easy
to get and many well-known vendors have them).
If it is an Enterprise Code they recognise they process according to their own
vendor-specific knowledge about the contents.
If they don't recognise the Enterprise Code, they fail the processing.
An Enterprise will often (always?) define their own structure starting with a
version number or something similar, and often using TLVs.

What have I missed about moving targets?

Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 23 Jan 2015 18:59:08 -0000

Thanks for being awake, Kam.
 
Useful info.
 
Gert, the OUI registry is an IEEE registry as Kam says. IANA has a registry page
for this, but it points to the IEEE page.
 
As I understand Kam, 874.1 is not yet updated so it would be premature to point
to it, but an option is to attempt to match it now and fix later if needed.
 
Adrian
 
From: Lam, Hing-Kam (Kam) [mailto:[email-masked]] 
Sent: 23 January 2015 17:10
To: Gert Grammel; [email-masked]; 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); [email-masked];
[email-masked]; [email-masked]
Subject: RE: [CCAMP] Vendor-Specific Application Code in
draft-ietf-ccamp-rwa-wson-encode
 
Hi Gert,
 
A vendor can purchase an OUI (Organizationally Unique Identifier) from the IEEE
Registration Authority.
Once a vendor has its OUI, the vendor can manage its vendor-specific application
identifiers under its own OUI. 
SG15 doesn't need to host any registry for this purpose.
 
Regards,
Kam
 
From: Gert Grammel [mailto:[email-masked]] 
Sent: Friday, January 23, 2015 11:49 AM
To: Lam, Hing-Kam (Kam); [email-masked]; 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); [email-masked];
[email-masked]; [email-masked]
Subject: RE: [CCAMP] Vendor-Specific Application Code in
draft-ietf-ccamp-rwa-wson-encode
 
Hi Kam,
 
Is SG15 considering to host a registry for the vendor specific application code
or is the IETF registry supposed to be used?
 
Thanks
 
Gert
 
From: CCAMP [mailto:[email-masked]] On Behalf Of Lam, Hing-Kam (Kam)
Sent: 23 January 2015 17:03
To: [email-masked]; 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); [email-masked];
[email-masked]; [email-masked]
Subject: Re: [CCAMP] Vendor-Specific Application Code in
draft-ietf-ccamp-rwa-wson-encode
 
Dear all,
 
For your information. In the last SG15 meeting, Q14/15 agreed to update G.874.1
to amend the specification of ApplicationIdentifier with the following
additional text:
 
If the ApplicationIdentifierType is STANDARD, the value of PrintableString
represents a standard application code as defined in the ITU-T Recommendations.
If the ApplicationIdentifierType is PROPRIETARY, the first six characters of the
PrintableString must contain the Hexadecimal representation of an OUI assigned
to the vendor whose implementation generated the Application Identifier; the
remaining octets of the PrintableString are unspecified.
 
Paul Doolan had an I-D
"https://tools.ietf.org/html/draft-doolan-proprietary-ac-00" to the last IETF
meeting with the similar proposal.
 
Regards,
Kam
 
-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Friday, January 23, 2015 9:41 AM
To: 'Giovanni Martinelli (giomarti)'
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: [CCAMP] Vendor-Specific Application Code in
draft-ietf-ccamp-rwa-wson-encode
 
Hi,

 

 
 
Thanks,
Adrian
 
> <[email-masked]>
it is
the
format,
then
is my
(I
class
value
leaving
leave
Class,

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Mon, 26 Jan 2015 01:49:42 +0000

Hi Adrian,

Yes, while Q14/15 already reached agreement to update the Application Identifier description, the update has not been formally approved and published by SG15 yet. Q14/15 may be able to consent this update as an Amendment to G.874.1 at the upcoming SG15 meeting in July 2015.

Regards,
Kam

From: Adrian Farrel [mailto:[email-masked]]
Sent: Friday, January 23, 2015 1:59 PM
To: Lam, Hing-Kam (Kam); 'Gert Grammel'; 'Giovanni Martinelli (giomarti)'
Cc: 'Doolan, Paul (Coriant - US/Irving)'; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

Useful info.

Gert, the OUI registry is an IEEE registry as Kam says. IANA has a registry page for this, but it points to the IEEE page.

As I understand Kam, 874.1 is not yet updated so it would be premature to point to it, but an option is to attempt to match it now and fix later if needed.

Adrian

To: Gert Grammel; [email-masked]<mailto:[email-masked]>; 'Giovanni Martinelli (giomarti)'

Hi Gert,

Regards,
Kam

To: Lam, Hing-Kam (Kam); [email-masked]<mailto:[email-masked]>; 'Giovanni Martinelli (giomarti)'

Hi Kam,

Thanks

Gert

Dear all,

Regards,

Kam

-----Original Message-----

Hi,

   document

   Code field.

Thanks,

Adrian

it is

the

format,

then

is my

(I

class

value

leaving

leave

Class,

CCAMP mailing list

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 28 Jan 2015 17:45:30 +0000

Hi All,

As Lou noted, Adrian's option 1 was the intention as this was discussed when G872 was being revised to introduce Application Identifier (IETF's March 2013 meeting). As Kam notes, ITU's work on G.874.1 has evolved to include the OUI.

As a network operator, I prefer as Adrian says - let's attempt to match draft G.874.1 (it does have agreement). So Adrian's option 2. While the context of this work is within an operator's network, the OUI will help to ensure interoperability.

Adrian - good catch-
Deborah

From: CCAMP [mailto:[email-masked]] On Behalf Of Lam, Hing-Kam (Kam)
Sent: Sunday, January 25, 2015 8:50 PM
To: [email-masked]; 'Gert Grammel'; 'Giovanni Martinelli (giomarti)'
Cc: 'Doolan, Paul (Coriant - US/Irving)'; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

Hi Adrian,

Regards,
Kam

Cc: 'Doolan, Paul (Coriant - US/Irving)'; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Useful info.

Adrian

Hi Gert,

Regards,
Kam

Hi Kam,

Thanks

Gert

Dear all,

Regards,

Kam

-----Original Message-----

Hi,

   document

   Code field.

Thanks,

Adrian

it is

the

format,

then

is my

(I

class

value

leaving

leave

Class,

CCAMP mailing list

---

From: Leeyoung <[email-masked]>
Date: Wed, 28 Jan 2015 19:32:30 +0000

Hi Deborah,

Thanks for sharing your operator's perspective.  I am wondering how the OUI would really help for interoperability other than identifying the specific vendors that are using their proprietary code.

Say vendor A uses FEC type A while vendor B used FEC type B, and both of them are proprietary FECs. I believe the OUI will help the operator identify this fact and conclude the systems are not compatible. But would this really help operators toward interoperability? I believe a better way for operators to attain interoperability is to force vendors use standard FECs and have them agree on the same type of FECs within the standard FECs. My point is how vendor specific code would be really helpful even if we employ the OUI field.

Thanks,
Young

From: CCAMP [mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A
Sent: Wednesday, January 28, 2015 11:46 AM
To: Lam, Hing-Kam (Kam); [email-masked]; 'Gert Grammel'; 'Giovanni Martinelli (giomarti)'
Cc: 'Doolan, Paul (Coriant - US/Irving)'; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

Hi All,

Adrian - good catch-
Deborah

Hi Adrian,

Regards,
Kam

Useful info.

Adrian

Hi Gert,

Regards,
Kam

Hi Kam,

Thanks

Gert

Dear all,

Regards,

Kam

-----Original Message-----

Hi,

   document

   Code field.

Thanks,

Adrian

it is

the

format,

then

is my

(I

class

value

leaving

leave

Class,

CCAMP mailing list

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 28 Jan 2015 19:55:48 +0000

Hi Young,

Are you voting for option 3?

My thoughts were if (big IF) we are going to allow proprietary Application Identifiers (which SG15 has agreed) then best would be if we can at least have some way to identify (better than an undefined string). As you say, it still does not guarantee interoperability unless it is the same vendor (hopefully ). If two different vendors (e.g. black link), then it would be for the vendors (and operator) to ensure interoperability if supporting non-standard AIs. And as we know, it's not just the AI that is needed to determine if it will work properly.

Thanks,
Deborah

From: Leeyoung [mailto:[email-masked]]
Sent: Wednesday, January 28, 2015 2:33 PM
To: BRUNGARD, DEBORAH A; Lam, Hing-Kam (Kam); [email-masked]; 'Gert Grammel'; 'Giovanni Martinelli (giomarti)'
Cc: 'Doolan, Paul (Coriant - US/Irving)'; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

Hi Deborah,

Thanks,
Young

To: Lam, Hing-Kam (Kam); [email-masked]<mailto:[email-masked]>; 'Gert Grammel'; 'Giovanni Martinelli (giomarti)'

Hi All,

Adrian - good catch-
Deborah

To: [email-masked]<mailto:[email-masked]>; 'Gert Grammel'; 'Giovanni Martinelli (giomarti)'

Hi Adrian,

Regards,
Kam

Useful info.

Adrian

Hi Gert,

Regards,
Kam

Hi Kam,

Thanks

Gert

Dear all,

Regards,

Kam

-----Original Message-----

Hi,

   document

   Code field.

Thanks,

Adrian

it is

the

format,

then

is my

(I

class

value

leaving

leave

Class,

CCAMP mailing list

---

From: Leeyoung <[email-masked]>
Date: Wed, 28 Jan 2015 20:05:09 +0000

Hi Deborah,

I agree with what you said. That was my point. Option 1 is my preference and the WG has agreed on that ,I think.

Thanks,
Young

From: BRUNGARD, DEBORAH A [mailto:[email-masked]]
Sent: Wednesday, January 28, 2015 1:56 PM
To: Leeyoung; Lam, Hing-Kam (Kam); [email-masked]; 'Gert Grammel'; 'Giovanni Martinelli (giomarti)'
Cc: 'Doolan, Paul (Coriant - US/Irving)'; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

Hi Young,

Thanks,
Deborah

Hi Deborah,

Thanks,
Young

Hi All,

Adrian - good catch-
Deborah

Hi Adrian,

Regards,
Kam

Useful info.

Adrian

Hi Gert,

Regards,
Kam

Hi Kam,

Thanks

Gert

Dear all,

Regards,

Kam

-----Original Message-----

Hi,

   document

   Code field.

Thanks,

Adrian

it is

the

format,

then

is my

(I

class

value

leaving

leave

Class,

CCAMP mailing list

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Wed, 28 Jan 2015 20:16:46 +0000

Dear all,

I'm getting a bit confused - I thought that there was sentiment to match the approach in G.874.1; wasn't that option 2?

Best regards,
Eve

From: Leeyoung [mailto:[email-masked]]
Sent: Wednesday, January 28, 2015 03:05 PM
To: BRUNGARD, DEBORAH A <[email-masked]>; Lam, Hing-Kam (Kam); [email-masked] <[email-masked]>; 'Gert Grammel' <[email-masked]>; 'Giovanni Martinelli (giomarti)' <[email-masked]>
Cc: 'Doolan, Paul (Coriant - US/Irving)' <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

Hi Deborah,

Thanks,
Young

Hi Young,

My thoughts were if (big IF) we are going to allow proprietary Application Identifiers (which SG15 has agreed) then best would be if we can at least have some way to identify (better than an undefined string). As you say, it still does not guarantee interoperability unless it is the same vendor (hopefully ). If two different vendors (e.g. black link), then it would be for the vendors (and operator) to ensure interoperability if supporting non-standard AIs. And as we know, it’s not just the AI that is needed to determine if it will work properly.

Thanks,
Deborah

Hi Deborah,

Thanks for sharing your operator’s perspective.  I am wondering how the OUI would really help for interoperability other than identifying the specific vendors that are using their proprietary code.

Thanks,
Young

Hi All,

As Lou noted, Adrian’s option 1 was the intention as this was discussed when G872 was being revised to introduce Application Identifier (IETF’s March 2013 meeting). As Kam notes, ITU’s work on G.874.1 has evolved to include the OUI.

As a network operator, I prefer as Adrian says – let’s attempt to match draft G.874.1 (it does have agreement). So Adrian’s option 2. While the context of this work is within an operator’s network, the OUI will help to ensure interoperability.

Adrian – good catch-
Deborah

Hi Adrian,

Regards,
Kam

Useful info.

Adrian

Hi Gert,

A vendor can purchase an OUI (Organizationally Unique Identifier) from the IEEE Registration Authority.
Once a vendor has its OUI, the vendor can manage its vendor-specific application identifiers under its own OUI.
SG15 doesn’t need to host any registry for this purpose.

Regards,
Kam

Hi Kam,

Thanks

Gert

Dear all,

Regards,

Kam

-----Original Message-----

Hi,

   document

   Code field.

Thanks,

Adrian

it is

the

format,

then

is my

(I

class

value

leaving

leave

Class,

CCAMP mailing list

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 28 Jan 2015 20:41:19 -0000

Eve,
 
What joy!
 
We've waited all these years to be identically confused:-)
 
I think the confusion may come from Young saying that knowing the OU makes no difference to interop.
I think that is false because:
- you have no way to know that your neighbor is from the same vendor
  (recall, this is an MCN protocol)
- your device might support working with multiple vendors
 
So there are two possible interworking issues:
1. You might crash trying to process a field assuming it is one of yours when it isn't
2. You might be unable to disambiguate for real interop choices
 
The proposed G.874.1 approach seems entirely painless to me and requires only one line of additional text. Viz.:
 
The format of the Vendor-Specific Application Identifier is a matter for the vendor concerned and may be private or published in vendor-specific documentation, but in all cases the first six characters of the Vendor-Specific Application Identifier MUST contain the hexadecimal representation of an OUI assigned to the vendor whose implementation generated the Application Identifier.
 
Is that so hard?
 
Adrian

From: Varma, Eve L (Eve) [mailto:[email-masked]] 
Sent: 28 January 2015 20:17
To: [email-masked]'; [email-masked]'; Lam, Hing-Kam (Kam); [email-masked]'; [email-masked]'; [email-masked]'
Cc: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
 
Dear all,

Best regards,
Eve

Hi Deborah,

Thanks,
Young

Hi Young,

 
Thanks,
Deborah

Hi Deborah,

 
Thanks,
Young 

Hi All,

 
Adrian – good catch-
Deborah

Hi Adrian,

Regards,
Kam

 
Useful info.

 
Adrian

Hi Gert,

Regards,
Kam

Hi Kam,

Thanks
 
Gert

Dear all,

 
 
Regards,
Kam
 
-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Friday, January 23, 2015 9:41 AM
To: 'Giovanni Martinelli (giomarti)'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode
 
Hi,

 

 
 
Thanks,
Adrian
 
it is
the
format,
then
is my
(I
class
value
leaving
leave
Class,

---

From: Leeyoung <[email-masked]>
Date: Wed, 28 Jan 2015 21:02:35 +0000

Hi,

There is always a priori knowledge in optical network domain as to who are you interfacing with. So you know which vendor you are interfacing. If you do not know, then you are in trouble.

Now, what is the purpose of standard FECs and modulations in the AI? Given several choices each vendor may support in its device, the path computation would find a matched types for FEC and modulation for a given optical path. This is what is intended when optical signal processing constraints were proposed as part of path computation constraints in optical networks.

There is very little chance for vendor specific FECs and Modulations will match even if they are identified with the OUI code.

My two cents,
Young

From: Adrian Farrel [mailto:[email-masked]]
Sent: Wednesday, January 28, 2015 2:41 PM
To: 'Varma, Eve L (Eve)'; Leeyoung; [email-masked]; 'Lam, Hing-Kam (Kam)'; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

Eve,

What joy!

Is that so hard?

Adrian

Dear all,

Best regards,
Eve

Hi Deborah,

Thanks,
Young

Hi Young,

Thanks,
Deborah

Hi Deborah,

Thanks,
Young

Hi All,

Adrian – good catch-
Deborah

Hi Adrian,

Regards,
Kam

Useful info.

Adrian

Hi Gert,

Regards,
Kam

Hi Kam,

Thanks

Gert

Dear all,

Regards,

Kam

-----Original Message-----

Hi,

   document

   Code field.

Thanks,

Adrian

it is

the

format,

then

is my

(I

class

value

leaving

leave

Class,

CCAMP mailing list

---

From: "Doolan, Paul (Coriant - US/Irving)" <[email-masked]>
Date: Wed, 28 Jan 2015 21:01:13 +0000

On Jan 28, 2015, at 2:32 PM, Leeyoung <[email-masked]<mailto:[email-masked]>>
 wrote:

Hi Young,

My point is how vendor specific code would be really helpful even if we employ the OUI field.

Without it there is risk of collision. A system that receives a proprietary code point it recognizes is, without the OUI, unable to tell whether that code point was generated by an equipment with the same proprietary implementation or by some other system that just happened to pick the same code.

pd

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 29 Jan 2015 03:46:05 +0000

Hi Young and all,

As an individual, I agree with Adrain, which means I would support Option 2.

I think we just need add some sentences to fit Option 2.

When s=0 and OI=1, the first 32 (or 48) bits of the Vendor-Specific Application Code field contain an Enterprise Number (or OUI) that defines the context in which the remainder of that field is interpreted. In addition, we need to add some text to describe the process rules that Adrian hinted below.

My question is:

Which number (either an Enterprise number or OUI) should be used? I think we just need pick one of them. If an Enterprise Number is used, it needs 32 bits, otherwise 48 bits should be used. If 48 bits are used, it needs to put one line more (32 bits) to the current format of Optical Interface Class.

To Young, you can also take a look at [draft-ietf-pce-rfc7150bis], which has some informaiton releated to Enterprise Number.

Best Regards

Fatai

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Saturday, January 24, 2015 2:46 AM
To: Leeyoung; 'Giovanni Martinelli (giomarti)'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

OK.

issues.

> It would be hard to catch moving target around this

> area if we were to take Option 2.

Cheers,

Adrian

---

From: Dieter Beller <[email-masked]>
Date: Thu, 29 Jan 2015 14:16:50 +0100

+1 (support for Option 2)

Thanks,

Dieter

On 29.01.2015 04:46, Fatai Zhang wrote:

Hi
Young and all,

As
an individual, I agree with Adrain, which means I would
support Option 2.

I
think we just need add some sentences to fit Option 2.

When
s=0 and OI=1, the first 32 (or 48) bits of the
Vendor-Specific Application Code field contain an Enterprise
Number (or OUI) that defines the context in which the
remainder of that field is interpreted. In addition, we need
to add some text to describe the process rules that Adrian
hinted below.

My
question is:

Which
number (either an Enterprise number or OUI) should be used?
I think we just need pick one of them. If an Enterprise
Number is used, it needs 32 bits, otherwise 48 bits should
be used. If 48 bits are used, it needs to put one line more
(32 bits) to the current format of Optical Interface Class.

To
Young, you can also take a look at
[draft-ietf-pce-rfc7150bis], which has some informaiton
releated to Enterprise Number.

Best
Regards

Fatai

-----Original
Message-----

Cc: [email-masked];
[email-masked]; [email-masked]

Subject: RE: Vendor-Specific Application Code in
draft-ietf-ccamp-rwa-wson-encode

> Thanks Adrian
for taking this on.

Well, we'll get there
eventually!

OK.

It is my least
favorite option because it is most likely to hit
interoperability

issues.

So, if the WG wants
to go this way, we will have to work a little to explain how

it works and why it
isn't a problem (specifically for the IESG).

> area if we were
to take Option 2.

I see no moving
targets at all.

This is how all other
vendor-specific fields are handled in protocols.

The way it works is
that anyone receiving such a field looks at the first 32

bits and interprets
it as an Enterprise Code from the IANA registry (hint: easy

to get and many
well-known vendors have them).

If it is an
Enterprise Code they recognise they process according to
their own

vendor-specific
knowledge about the contents.

If they don't
recognise the Enterprise Code, they fail the processing.

An Enterprise will
often (always?) define their own structure starting with a

version number or
something similar, and often using TLVs.

What have I missed
about moving targets?

Cheers,

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 29 Jan 2015 13:23:59 -0000

Hi again,

> There is always a priori knowledge in optical network domain as to who 
> are you interfacing with. So you know which vendor you are interfacing. 
> If you do not know, then you are in trouble.

Hmmm. It is exactly type of trouble we are trying to detect and protect against.

I refute your statement of a priori knowledge. I think there is a priori intention, but not knowledge. Unless you have very good eyesight or someone at the other end of the fiber when you give it a tug, you don't know. And even then. Fibering errors happen from time to time. Consider, in particular a patch panel.

> Now, what is the purpose of standard FECs and modulations in the AI? Given
> several choices each vendor may support in its device, the path computation
> would find a matched types for FEC and modulation for a given optical path. 
> This is what is intended when optical signal processing constraints were 
> proposed as part of path computation constraints in optical networks. 

The case you are making here is for no standard control plane!
What is the point of standardising if there is never any interworking?
But actually, we know about interworking at the physical layer, and (more important) we know about a single, end-to-end control plane that spans multiple vendor devices. It all exists.

Of course, we can fall back into the old-style vendor islands, and many like to do so. But it is not a compulsory deployment model.

> There is very little chance for vendor specific FECs and Modulations will match
> even if they are identified with the OUI code. 

You have it the wrong way round!
The OUI is largely to protect against expectations of interworking when none can exist.
It might (much less frequently) be used to describe the way that vendorA and vendorB pick FECs and modulations in order to achieve interworking.

Adrian

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 29 Jan 2015 14:49:12 +0100

All,

I agree with Adrians assessment.

+1 for option 2.

Regards, Huub.

========

-- 
*****************************************************************
               请记住，你是独一无二的，就像其他每一个人一样

---

From: Leeyoung <[email-masked]>
Date: Thu, 29 Jan 2015 14:51:20 +0000

Hi,

It seems like the world is against Option 1. No big deal, please provide relevant text to support Option 2. 

Young

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Thursday, January 29, 2015 7:24 AM
To: Leeyoung; 'Varma, Eve L (Eve)'; [email-masked]; 'Lam, Hing-Kam (Kam)'; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

Hi again,

Adrian

---

From: Lou Berger <[email-masked]>
Date: Thu, 29 Jan 2015 10:59:40 -0500

I thought it would be good to let things settle a bit before responding
as Shepherd.

So option 1 (No definition of proprietary semantics and conflicts are
handled outside of the control plane, i.e., belong to operator) was the
intent of the WG at the time of publication request.  This approach was
also aligned with the then, and actually current, state of the ITU-T
data plane (and management info) as discussed in our joint meeting. I
believe option 3 (dropping the vendor specific option) isn't in conflict
with this.

There now seems to be support for changing the document to align it
with, what I understand is, a planned update to G.874.1.  This of course
implies that such a change would result in this document being blocked
until that update is published in 6 months or so, and assumes no
substantive change its contents.

Again with Shepherd hat on, I recommend avoiding the additional delay
and not tie this document to the planned G.874.1 update at this time,
i.e., by following option 1 (or even 3).  This allows for a future
bis/update that is align with the expected update to G.874.1 once it is
published.

Comments, objections, support?  (AD, authors, chairs, wg, ...)

Lou

---

From: Gert Grammel <[email-masked]>
Date: Thu, 29 Jan 2015 16:00:02 +0000

Hi Leeyoung, 

Keep in mind that G.698.2 allows to use transceivers from different vendors, based on standard AIs (=Application Codes). Now in case of a multi-vendor network, *additional* proprietary application codes can be used if there is a pre-knowledge that the proprietary AIs match. I believe this was one case you were referring to.
So a single transceiver HW implementation supporting the standard-AI will almost certainly support also a vendor-AI e.g.,  if a higher level of OSNR can be tolerated than the standard-AI has encoded. Hence we can conclude that a single (vendor) transceiver potentially supports a list of AIs. So even by picking Option 2 your case can be addressed.

How to encode those AIs is another matter as printable strings are not always the best choice to use. https://tools.ietf.org/html/draft-martinelli-wson-interface-class-03 and https://tools.ietf.org/html/draft-dharini-netmod-g-698-2-yang-02 already provide some encoding, whereby OUI would need to be worked in.

Gert

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: 29 January 2015 14:24
To: 'Leeyoung'; 'Varma, Eve L (Eve)'; [email-masked]; 'Lam, Hing-Kam (Kam)'; Gert Grammel; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

Hi again,

> Now, what is the purpose of standard FECs and modulations in the AI? 
> Given several choices each vendor may support in its device, the path 
> computation would find a matched types for FEC and modulation for a given optical path.
> This is what is intended when optical signal processing constraints 
> were proposed as part of path computation constraints in optical networks.

> There is very little chance for vendor specific FECs and Modulations 
> will match even if they are identified with the OUI code.

Adrian

---

From: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]>
Date: Thu, 29 Jan 2015 16:07:28 +0000

Hi All, 

I'm in favour of option 2 as well.

I'd like to note that there are other drafts in ccamp that may be affected
by this change:
- draft-galikunze-ccamp-g-698-2-snmp-mib
- draft-dharinigert-ccamp-g-698-2-lmp
- draft-dharini-netmod-g-698-2-yang

I'm co-author of them and as such I'll coordinate with the other authors
to fix the drafts.

Best Regards, 

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

via S.Maria Molgora, 48 C
20871 - Vimercate (MB)
Italy
www.cisco.com/global/IT/ <http://www.cisco.com/global/IT/>

[email-masked]
Phone :+39 039 2091462
Mobile :+39 335 7481947
Fax :+39 039 2092049

On 1/29/15 2:23 PM, "Adrian Farrel" <[email-masked]> wrote:

>I refute your statement of a priori knowledge. I think there is a priori
>intention, but not knowledge. Unless you have very good eyesight or
>someone at the other end of the fiber when you give it a tug, you don't
>know. And even then. Fibering errors happen from time to time. Consider,
>in particular a patch panel.
>
>>Given
>>were 
>But actually, we know about interworking at the physical layer, and (more
>important) we know about a single, end-to-end control plane that spans
>multiple vendor devices. It all exists.
>
>Of course, we can fall back into the old-style vendor islands, and many
>like to do so. But it is not a compulsory deployment model.
>
>>will match
>It might (much less frequently) be used to describe the way that vendorA
>and vendorB pick FECs and modulations in order to achieve interworking.
>
>Adrian
>

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Thu, 29 Jan 2015 16:17:51 +0000

Hi, Lou, 
 
   I support your proposal. 

  Just a thought: given the massive support of Option 2 from WG,  maybe we can reconcile by moving the WG draft forward using either Option 1/3, while writing a short draft to document the update needed to match the to-be-updated G.874.1? So that once it is updated, we can move the draft quickly. 

Regards,
Xian

________________________________________
发件人: CCAMP [[email-masked]] 代表 Lou Berger [[email-masked]]
发送时间: 2015年1月29日 23:59
收件人: Leeyoung; [email-masked]; 'Varma, Eve L (Eve)'; [email-masked]; 'Lam, Hing-Kam (Kam)'; [email-masked]; [email-masked]
抄送: [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 29 Jan 2015 11:22:00 -0500

On 01/29/2015 11:17 AM, Zhangxian (Xian) wrote:
> Hi, Lou, 
>  
>    I support your proposal. 
> 
> Just a thought: given the massive support of Option 2 from WG,  maybe
> we can reconcile by moving the WG draft forward using either Option
> 1/3, while writing a short draft to document the update needed to
> match the to-be-updated G.874.1? So that once it is updated, we can
> move the draft quickly.
> 

Seems right to me (as contributor)

Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 29 Jan 2015 16:34:00 +0000

I think Xian's proposal makes sense.

I would like not to hold the draft for 6 more months. 
As chair I would suggest to go for option 1 or 3 and then go for a bis when G.874.1 will be consented.
As contributor, among 1 and 3 I would prefer 1 but I think 3 leaves more room for a simple and straightforward bis.

Opinions on this last statement?

BR
Daniele

> From: CCAMP [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: giovedì 29 gennaio 2015 17:22
> To: Zhangxian (Xian)
> > 收件人: Leeyoung; [email-masked]; 'Varma, Eve L (Eve)';
> > [email-masked]; 'Lam, Hing-Kam (Kam)'; [email-masked];
> > [email-masked]
> > 抄送: [email-masked]; [email-masked];
> > [email-masked];
> > I thought it would be good to let things settle a bit before
> > responding as Shepherd.
> >
> > handled outside of the control plane, i.e., belong to operator) was
> > the intent of the WG at the time of publication request.  This
> > approach was also aligned with the then, and actually current, state
> > of the ITU-T data plane (and management info) as discussed in our
> > joint meeting. I believe option 3 (dropping the vendor specific
> > option) isn't in conflict with this.
> >
> > with, what I understand is, a planned update to G.874.1.  This of
> > course implies that such a change would result in this document being
> > blocked until that update is published in 6 months or so, and assumes
> > no substantive change its contents.
> >
> > bis/update that is align with the expected update to G.874.1 once it
> > is published.
> >
> >> To: Leeyoung; 'Varma, Eve L (Eve)'; [email-masked]; 'Lam, Hing-Kam
> >> (Kam)'; [email-masked]; [email-masked]
> >> Cc: [email-masked]; [email-masked];
> >> [email-masked];
> >>> There is always a priori knowledge in optical network domain as to
> >>> who are you interfacing with. So you know which vendor you are
> interfacing.
> know. And even then. Fibering errors happen from time to time. Consider, in
> particular a patch panel.
> >>
> >>> Given several choices each vendor may support in its device, the
> >>> path computation would find a matched types for FEC and modulation
> for a given optical path.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 29 Jan 2015 17:17:45 -0000

Hi,

It is worth looking at how you would do the bis.

Option 1 says that an implementation can put absolutely anything in the field
under a single code point.
If you want to bis that, you automatically make all implementations broken
unless you define a new OI so you would have ...
0 reserved
1 vendor-specific unknown format
2 (in the bis) vendor-specific with OUI

Option 3 says that *today* there is no such thing as vendor-specific AI. In that
case the code point is not even seen and implementations today cannot do vendor
specific stuff.
So you would have S=0 reserved
And you would bis by S=1 means vendor-specific.

Either approach works.

Now, let's discuss existing implementations.
AFAICS no-one is close to shipping product (please tell me if I am wrong).
So there is no rush.

Now let's discuss timing.
Option 1 and option 3 allow publication soon, with a bis later. The bis would
not happen until the ITU-T has finalised the format for vendor-specific AIs
Option 2 can be approached two ways
a. *Guess* which way the ITU-T will define the vendor-specific AI
b. Wait until the ITU-T has finalised the format for vendor-specific AIs.

I would like the chairs to help me and the shepherd understand the preferred
approach so that we can determine what to do with the document.

Thanks,
Adrian

> From: CCAMP [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
> Sent: 29 January 2015 16:34
> To: Lou Berger; Zhangxian (Xian)
> As chair I would suggest to go for option 1 or 3 and then go for a bis when G.
874.1
> will be consented.
> As contributor, among 1 and 3 I would prefer 1 but I think 3 leaves more room
for
> a simple and straightforward bis.
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 29 Jan 2015 12:32:54 -0500

Adrian,
	
> approach so that we can determine what to do with the document.

I read your message as saying you think option 3 is the better way to go
wrt a future bis.  I see traffic on the list supporting this.  As
Shepherd I think this would be fine.

Unless I'm misreading you, let's move forward with making the changes to
the document to drop support for "vendor-specific unknown format".  It
will take a day or two for the authors to get the revision out, and this
will give others a chance to chime in (i.e, oppose) this if they disagree.

Thanks,
Lou

---

From: Leeyoung <[email-masked]>
Date: Thu, 29 Jan 2015 18:57:08 +0000

Hi Gert,

Yes, you hit the nail on the head. Thanks.

It looks like we can move on this issue with the latest development in this thread.

Best regards,
Young

-----Original Message-----
From: Gert Grammel [mailto:[email-masked]] 
Sent: Thursday, January 29, 2015 10:00 AM
To: [email-masked]; Leeyoung; 'Varma, Eve L (Eve)'; [email-masked]; 'Lam, Hing-Kam (Kam)'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

Hi Leeyoung, 

Gert

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: 29 January 2015 14:24
To: 'Leeyoung'; 'Varma, Eve L (Eve)'; [email-masked]; 'Lam, Hing-Kam (Kam)'; Gert Grammel; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

Hi again,

Adrian

---

From: Leeyoung <[email-masked]>
Date: Thu, 29 Jan 2015 19:10:50 +0000

Hi Adrian,

I think you misinterpreted what was said. 

> But actually, we know about interworking at the physical layer, and (more important) we know about a single, > end-to-end control plane that spans multiple vendor devices. It all exists.

The standard AI allows to match optical processing constraints (including FECs and Modulations implied in an AI). This information is advertised that a PCE would be able to compute an optical path matching AIs for all the devices to dertermine a feasible path. I am talking about this standard control plane work. This is what was intended in the draft. 

Regards,
Young

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Thursday, January 29, 2015 7:24 AM
To: Leeyoung; 'Varma, Eve L (Eve)'; [email-masked]; 'Lam, Hing-Kam (Kam)'; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

Hi again,

Adrian