Re: Review of draft-ietf-nsis-qspec-18.txt

Ken,
   
  >> Right, there is no issue in having an IETF spec tied to an ITU spec.  
  >> If ITU modifies their spec, IANA will make the corresponding changes
  >> in the IETF IANA assignments.  E.g., if ITU later standardizes more
  >> priority levels, say in "Y.2171.bis', IANA will change the 
  >> admission priority registry accordingly.  I checked that out with IANA
  >> a while ago, IANA can tie into ITU specs in this way.
  

  > if the Admission field in the QSPEC is to be so entwined with Y.1541
  > values (and possibly Y.2171.bis), then perhaps the Admission field
  > in QSPEC should be renamed as ITU-Admission?
    > Or possibly one could define a new field called ITU-admission that
  > supports the Y.1541 pre-defined values.  It would also seem helpful to
  > add another related field that indicates which Y.xxxx standard is being
  > used since there may be some domains that only support Y.1541,
  > others supporting Y.2171.bis, and whatever future iteration is defined
  > by the ITU.  I assume  folks are not relying on a flag day change in
  > support of new updates generated by the ITU?

   
  This is confusing to me because admission priority has nothing to do with Y.1541.  Y.1541 is associated with the <Y.1541.QoS Class> field (see Section 5.2.14 of the updated -19 QSPEC document or Section 6.2.14 of the current -18 QSPEC document).  
   
  QSPEC admission priority is simply using the 3 priority levels already standardized by Y.2171.  Admission priority is a generic concept, not invented by the ITU, so this is not 'ITU admission priority', just plain ole' admission priority.
   
  What's missing here is an explanation of what the approach is in [EMERGENCY-RSVP].  As I posted earlier in http://www.ietf.org/mail-archive/web/nsis/current/msg08231.html:
   
  "QSPEC is ... standardizing 3 priority levels to have end-to-end cross-domain significance.   
  If we elimate this standardization, as is proposed (in [EMERGENCY-RSVP]), then different admission priority values can be assigned in different Admin domains, and will have no end-to-end significance.  For example, Admin-domain 1, Admin-domain 2, and Admin-domain 3 assign admission priority=2,  admission priority=4, admission priority=10 for the highest level priority, respectively.  Admin-domain 1 and Admin-domain 2 try to initiate end-to-end flows via Admin-domain 3 for a 'high priority' flow.  However, Admin-domain 3 has no idea how to treat the flow admission priority since all 3 domains are using different encodings of high priority."
   
  I've not seen a response to the above example and/or an explanation of how the [EMERGENCY-RSVP] approach achieves end-to-end cross-domain standardization?
   
  Perhaps it is some different approach to priority more like preemption priority?  Perhaps the [EMERGENCY-RSVP] approach should be called "RSVP-priority"?
   

  > and as far as the current values set by Y.1541, I wish there was support
  > for Scavenger Service, which is considered less than Best Effort (already
  > defined as "0" in Y.1541).
   
  I'm not sure what your suggestion is here for Y.1541, but perhaps that should be discussed on a separate thread (perhaps associated with the Y.1541-QOSM draft http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-06.txt)?
   
  Thanks,
  Jerry

ken carlberg <[email protected]> wrote:
    Jerry,
  

  > Right, there is no issue in having an IETF spec tied to an ITU spec.  If ITU modifies their 
  > spec, IANA will make the corresponding changes in the IETF IANA assignments.  E.g., if 
  > ITU later standardizes more priority levels, say in "Y.2171.bis', IANA will change the 
  > admission priority registry accordingly.  I checked that out with IANA a while ago, IANA can 
  > tie into ITU specs in this way.
  

  if the Admission field in the QSPEC is to be so entwined with Y.1541 values (and possibly Y.2171.bis), then perhaps the Admission field in QSPEC should be renamed as ITU-Admission?  Or possibly one could define a new field called ITU-admission that supports the Y.1541 pre-defined values.  It would also seem helpful to add another related field that indicates which Y.xxxx standard is being used since there may be some domains that only support Y.1541, others supporting Y.2171.bis, and whatever future iteration is defined by the ITU.  I assume  folks are not relying on a flag day change in support of new updates generated by the ITU?
  

  and as far as the current values set by Y.1541, I wish there was support for Scavenger Service, which is considered less than Best Effort (already defined as "0" in Y.1541).  Since I'm not a member of the ITU, I can't advocate this position nor accomplish it if the Admission field of all three drafts <emergency-rsvp>, <dime-qos-parameters> and <nsis-qspec> are subject to values defined by the ITU.
  

  and please note, I'm not saying that a field cannot reflect efforts put forth by the ITU, but rather if the need must exist, then I'd prefer that the QSPEC authors rename or create a new field for Y.1541 or Y.2171.bis
  

  regards,
  

  -ken
  



       
---------------------------------
Never miss a thing.   Make Yahoo your homepage.

_______________________________________________
nsis mailing list
[email protected]
http://www.ietf.org/mailman/listinfo/nsis