Subject: Re: Question on draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt

From: [email-masked]
Date: Thu, 1 Mar 2007 08:54:53 +0100

hi vijay

technology specific information encoding as part
of the techno specific field of the ISCD sub-TLV
is outside scope of this document, that defines
the generic routing mechanisms for OSPF

the paragraph you pointed is given as example, to
clearly indicate where this information has to be
encoded but is not going to be further detailed

in other terms techno-specific bw accounting is
outside the scope of the document

thanks,
- d.

"Pandian, Vijay" <[email-masked]>
Sent by: [email-masked]
01/03/2007 03:35
 
        To:     <[email-masked]>
        cc: 
        Subject:        Question on 
draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt

Hi,
 
In section 4.2 Technology Specific Bandwidth Accounting, it says:
 
   In the ASON context, accounting on per timeslot basis using 32-bit 
   tuples of the form <signal_type (8 bits); number of unallocated 
   timeslots (24 bits)> may optionally be incorporated in the 
   technology specific field of the ISCD TE link attribute when the 
   switching capability field is set to TDM value. When included, 
   format and encoding MUST follow the rules defined in [RFC4202]. 
 
The signal types as defined in RFC4606 Section 2.1 covers a basic set. The 
signal type is used in conjunction with the other attributes like RCC, 
NCC, etc., to determine other Elementary Signal such as STS-12c SPE, 
STS-48c SPE, STS-192c SPE etc.
 
It is not clear to me how this 8-bit filed could be used to cover all the 
different types of signal types.
 
Thanks and best regards,
 
Vijay

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 1 Mar 2007 11:05:51 -0000

Hi,

From which response, I interpret Dimitri as saying that:

"Further, technology-specific documents might be written to define standard 
encoding of this (and other?) fields of the ISCD sub-TLV."

Is that correct?

The text in 4.2 appears more definitive than that. Perhaps, if the text 
shows just a potential encoding and not a defined encoding, you might 
consider making that very clear of removing the text?

Thanks,
Adrian