Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 (Issue 1/2)

[Lou Berger <[e-mail]>]

John,
	As you probably know, each time we have new technology or a
change/evolution in a technology the folks involved in the technology
come up with a fairly technology-specific solution to their problem.
Part of the WG process has always been looking at the technology
specific extensions and figuring out what, if any, impact the
technlogy-specific extensions should have on the common portion of
GMPLS.  Prior to OTNv3, this can most recently be seen in both the
ethernet and WSON WG work.  In these cases, WG participants triggered
generalization of the proposed mechanisms.  This was even the case for
Ethernet, where I was on the other side as an author and the WG prompted
taking one document and making it 3.  IMO, as both a WG participant and
co-chair (yes, this time I'm making a statement as a Chair!), this
process is consistent, and required, by both the CCAMP's charter and WG
procedural precedent.   It is also exactly what we, the co-chairs, said
in our OTN discussion at IETF-78. (We mentioned defining new common
mechanisms as part of the solution refinement stage.)

In this case the OTN documents are not proposing a new mechanism, but
rather using a technology-specific approach.  Furthermore, in our
discussions you proposed modifying/deprecating documented usage /
meaning of SC Type.  I still see this as fitting within 'defining new
common mechanisms as part of the solution refinement stage.'

As you also may recall, the usage of SC type has come up multiple times
since it was introduced (perhaps by Yakov?).  I think (again as
participant and chair) it would be good to close this issue once and for
all.

See below for specific responses (as a WG participant).

On 12/20/2011 4:37 PM, John E Drake wrote:
> Lou,
> 
> I don't see any inconsistency between the two statements.  Nobody
> uses PSC 1-4 so we don't have to touch it and the SDH/SONET model,
> which we are re-using, is already consistent with base GMPLS - what
> is advertised for an interface is a single switching type, the types
> of client signals it supports, and its available bandwidth.
> 
> How does the existence of this draft, which will have no new
> information, help the chairs gauge rough consensus on this issue in
> the WG, 

It depends on which issue you are talking about.  If talking about the
general issue as discussed above, I hope it will close it for the future.

If talking about my (individual, not chair) proposal of using multiple
SC types for OTNv3, I don't think it immediately does.  What it will do
is provide context for that proposal.  In the interim, I recommend (as a
WG participant, not chair) tabling discussion on my proposal until we
know which way the general issue is resolved.

> especially since rough consensus seems to already exist?
> (I.e., the editors, authors, and contributors of the OTN routing
> draft would seem to represent a substantial portion of the WG.)

Well if the WG used this as the sole measure, consensus could have been
declared in Maastrict.

Lou

PS I've noted where I'm speaking as an individual WG participant and
where I'm expressing opinions as a Co-chair as this message contains both.

> 
> Thanks,
> 
> John 
> 
>> -----Original Message-----
>> From: Lou Berger [mailto:[e-mail]]
>> Sent: Tuesday, December 20, 2011 12:22 PM
>> To: John E Drake
>> Cc: Sadler, Jonathan B.; BELOTTI, SERGIO (SERGIO); CCAMP
>> Subject: Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82
>> (Issue 1/2)
>>
>>
>> On 12/20/2011 2:02 PM, John E Drake wrote:
>>>>> In an earlier message I asked if you were interested in putting a
>> draft
>>>>> together to document your proposed change to the base GMPLS specs.
>>> [
>>> [JD]  There are no changes to the base GMPLS specs.  We are not
>> changing the base definition of PSC 1-4 and what we are defining is
>> completely consistent with SDH/SONET.
>>>
>>
>> John,
>> 	In an earlier message you said:
>>
>> On 11/30/2011 5:23 PM, John E Drake wrote:
>>> Yes, I think that's fair.
>>>
>>>>> -----Original Message-----
>>>>> From: Lou Berger [mailto:[e-mail]]
>>>>> Sent: Wednesday, November 30, 2011 1:51 PM
>>>>> To: John E Drake
>>>>> Cc: Daniele Ceccarelli; CCAMP
>>>>> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue
>> 1/2)
>>>>>
>>>>> So you're basically arguing that SC shouldn't be used to indicate
>>>>> different levels of hierarchy, i.e., usage (b) in my earlier
>> message,
>>>>> and that the definition of PSC-1 -> n was flawed.  Right?
>>>>>
>>>>> Which then reduces the meaning of SC to simply and indicator of
>> label
>>>>> type and ISCD format indicator.
>>>>>
>>>>> Is this your position?
>>>>>
>>
>> Deprecating PSC1-4 and making SC Type just an indicator of label and
>> ISCD format will be covered in the draft. The draft wouldn't say
>> anything specifically about OTN.
>>
>> Lou
>>
>>
>>
>