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

[Daniele Ceccarelli <[e-mail]>]

All,

Just to add a consideration that has not been taken into account up to now.

We said that for congurence with RFC4203 we should reuse the different layers in the SC field as per PSC [1~4], but at the same time RFC4328 defines a single ODU value, and a that time three different "layers" already existed: ODU1, ODU2, ODU3...so in order to be consistence with RFC4328 we should not use different layers in the SC field.

We already passed the brach, let's make a decision, one or the other, but we can no longer look back.

I agree with what Jonathan and John said before and support the single SC option.

I also take the opportunity of this mail to wish all of you a very Merry Christmas.

Daniele

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 
>On Behalf Of John E Drake
>Sent: mercoledì 21 dicembre 2011 18.40
>To: Sadler, Jonathan B.; Lou Berger
>Cc: CCAMP
>Subject: Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 
>82 (Issue 1/2)
>
>Jonathan,
>
>The definitions in Switching Capability and Encoding Type were 
>attempts to be forward looking; AKA "everything but the 
>kitchen sink" 8->.   
>
>I think you raise a very good point regarding namespace exhaustion.
>
>Thanks,
>
>John
>
>> -----Original Message-----
>> From: Sadler, Jonathan B. [mailto:[e-mail]]
>> Sent: Wednesday, December 21, 2011 8:50 AM
>> To: John E Drake; Lou Berger
>> Cc: BELOTTI, SERGIO (SERGIO); CCAMP
>> Subject: RE: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 
>> (Issue 1/2)
>> 
>> Hi John and Lou,
>> 
>> I also have been participating in the GMPLS discussions from 
>early on 
>> (2002).
>> 
>> One item that always struck me funny the way GMPLS describes (ITU-T) 
>> layers by a tuple of information (e.g. <SwichCap, EncodType> or 
>> <SwitchCap, EncodType, SigType> for SDH/OTN) where the component 
>> information seems to be empirically defined.  More specifically:
>>  - Switching Capability defines some things based on large sweeping 
>> definitions but others more narrowly.  For example:
>>       TDM (which encompasses SONET/SDH and ODU)
>>    compared with:
>>       PSCx (which looks to be used only for MPLS)
>>       L2SC (which originally meant a combination of Frame Relay,
>> Ethernet)
>>  - Encoding type defines sub-categories of Switching Capability, but 
>> doesn't scope under Switching Capability.  For example:
>>       ANSI/ETSI PDH - when would this be used for a SC other 
>than TDM?
>>       SONET/SDH - ditto
>>       ODU - ditto (prior to use of the new 101 SC)
>>    compared with:
>>       Packet (This is not really descriptive)
>>       Ethernet (more descriptive - looks to be a 
>sub-category of L2SC.
>> Of course, this has been deprecated.)
>> 
>> Signal Type is definitely a sub-space of <TDM, OTN> and <TDM, SDH>.
>> 
>> Regarding the issue at hand: what is probably more important is how 
>> well these namespaces are used.  Since each component is a 
>8-bit value 
>> (today), exhaust is a real problem - especially since there is no 
>> hierarchy/sub-spacing for SwitchCap and EncodType.
>> 
>> 
>> It is because of namespace usage, I am not in favor of assigning a 
>> Switching capability per ODU type (i.e. ODU0, ODU1, ODU2, 
>ODU3, ODU4).
>> 
>> Jonathan Sadler
>> 
>> 
>> -----Original Message-----
>> From: John E Drake [mailto:[e-mail]]
>> Sent: Tuesday, December 20, 2011 6:17 PM
>> To: Lou Berger
>> Cc: Sadler, Jonathan B.; BELOTTI, SERGIO (SERGIO); CCAMP
>> Subject: RE: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 
>> (Issue 1/2)
>> 
>> 
>> 
>> > -----Original Message-----
>> > From: Lou Berger [mailto:[e-mail]]
>> > Sent: Tuesday, December 20, 2011 3:24 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)
>> >
>> > 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.)
>> 
>> [JD]  As you probably know, I have been one of the most vocal 
>> proponents of generality/commonality/reuse since the beginning of 
>> GMPLS back in 1999 (or so).
>> 
>> >
>> > In this case the OTN documents are not proposing a new mechanism, 
>> > but rather using a technology-specific approach.
>> 
>> [JD]  I really disagree with this characterization.  The correct 
>> statement would be that the decision to overload Switching 
>Capability 
>> to delineate presumed intra-region (layer) boundaries is made on a 
>> switching technology basis.  It was done for packet switching, PSC 
>> 1-4, but was not done for SDH/SONET and is currently not 
>done for OTN.
>> 
>> > 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.'
>> 
>> [JD]  Absent PSC 1-4, the usage of Switching Capability has always 
>> been as I described.  Interestingly enough, PSC 1-4 makes a lot more 
>> sense than your proposal.  For PSC 1-4 at least the 
>intra-region layer 
>> boundaries are under administrative control, while you are proposing 
>> to directly equate them with the underlying ODUk rates.  As 
>an aside, 
>> why is this not a "technology-specific approach"?
>> 
>> And you have yet to articulate any reason why this is necessary.  I 
>> think the quote from Sergio this morning was a compelling 
>and succinct 
>> rebuttal of its necessity.
>> 
>> >
>> > See below for specific responses (as a WG participant).
>> >
>> > > 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.
>> 
>> [JD]  The only issue is your specific proposal.
>> 
>> >
>> > > 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.
>> 
>> [JD]  The proposal developed in Maastricht was far more general than 
>> anything in base GMPLS.  The judgment articulated by the chairs in 
>> Beijing was that it was just too different from base GMPLs and that 
>> unfortunately it hadn't been thought of ten years earlier.
>> 
>> >
>> > 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.
>> 
>> [JD]  Are you referring to this specific email or in general?
>> 
>> ============================================================
>> The information contained in this message may be privileged and 
>> confidential and protected from disclosure. If the reader of this 
>> message is not the intended recipient, or an employee or agent 
>> responsible for delivering this message to the intended 
>recipient, you 
>> are hereby notified that any reproduction, dissemination or 
>> distribution of this communication is strictly prohibited. 
>If you have 
>> received this communication in error, please notify us 
>immediately by 
>> replying to the message and deleting it from your computer. 
>Thank you. 
>> Tellabs ============================================================
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp
>