Subject: Re: [NSIS] Admission field in QSPEC -- was RE: Review ofdraft-ietf-nsis-qspec-18.txt

From: "Martin Stiemerling" <[email-masked]>
Date: Fri, 7 Mar 2008 13:52:50 +0100

Hi Jerry,

Thanks for your summary and the proposal to change the field.

However, there current approach elimantes the idea of having an object understood by all participating partners (RSVP, NSIS, etc)  in terms of the admission priority.

The updated QSPEC will solely have the "Y.2171 Admission Priority" but no general purpose admission priority (as in  draft-ietf-tsvwg-emergency-rsvp). 

How about having the "Y.2171 Admission Priority" and the general purpose admission priority in the QSPEC?

Thanks,

  Martin

[email-masked]   <== NEW ADDRESS

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Gerald Ash
> Sent: Friday, February 29, 2008 7:46 PM
> To: nsis
> Cc: John Loughney
> Subject: Re: [NSIS] Admission field in QSPEC -- was RE: 
> Review ofdraft-ietf-nsis-qspec-18.txt
> 
> All,
>  
> I agree with Ken that we are talking past each other at this 
> point.  Magnus has requested to resolve this issue quickly, 
> so I also agree with Ken to resolve the issue based on his 
> suggestion in 
> http://www.ietf.org/mail-archive/web/nsis/current/msg08257.html:
>  
> "If the name of the field in Section 5.2.9 of the QSPEC is changed to
> "Y.2171 Admission Priority", I'll be more than happy to drop 
> the subject altogether, and suggest we'll note in 
> [emergency-rsvp] draft that Admission Priority field is not 
> directly comparable with that in the QSPEC so as to avoid confusion."
>  
> I agree that the qspec approach and emergency-rsvp approach 
> are not directly comparable, in fact, they are very 
> different.  At the risk of (again) 'being a bit much', let me 
> elaborate one more time on the differences as I see them:
>  
> As I've stated before, IMO admission priority should apply 
> end-to-end and across administrative domains, and the only 
> way to do that is to standardize the admission priority 
> values in an IANA registry.  This is the approach taken in 
> qspec, where the initial values to populate the admission 
> priority registry have been taken from Y.2171 since AFAIK 
> this is the only SDO to standardize admission priority levels 
> so far.  The process to standardize these has been rigorous 
> and agreed to by essentially all service providers (and 
> equipment vendors).  However, these are only initial values 
> to populate the registry and it does *not* mean that only the 
> ITU can change the registry to include more or changed 
> values.  E.g., Ken can propose his 'Scavenger Service' (less 
> than Best Effort) through the standard IANA procedure 
> specified in qspec Section 7 (IANA considerations):
>  
>   "Admission Priority Parameter (8 bits):
>    The following values are allocated by this specification:
>    0-2: assigned as specified in Section 6.2.9:
>    Admission Priority 0: best-effort priority flow
>                       1: normal priority flow
>                       2: high priority flow
>    The allocation policies for further values are as follows:
>    3-63: Standards Action
>    64-255: Reserved"
>  
> In addition, the qspec approach is the same as used in 
> practice today for emergency telecommunications services 
> (ETS, e.g., GETS) to achieve end-to-end admission priority 
> across domains.  One reference as how this approach operates 
> in practice today for ETS/GETS can be found in 
> http://www.amazon.com/Traffic-Engineering-Optimization-Integra
> ted-Networks/dp/0123706254/ (apologies for self reference, 
> but I'd be very happy to hear other references to 
> implementation examples).  The same reference also presents 
> extensive modeling & simulation analysis to show how this 
> approach can operate across domains in the Internet.
>  
> OTOH, the emergency-rsvp approach is very different.  It does 
> not prescribe end-to-end cross domain consist treatment of 
> admission priority.  As stated in Section 2 of emergency-rsvp:
>  
>   "As an example of operation across multiple administrative 
> domains, a 
>    first domain might decide to provide network layer 
> admission priority 
>    to calls of a given Application Level Resource Priority and map it 
>    into a high RSVP admission control priority inside the Admission 
>    Priority Policy Element; while a second domain may decide to not 
>    provide admission priority to calls of this same Application Level 
>    Resource Priority and hence map it into a low RSVP 
> admission control 
>    priority."
>  
> So in this RSVP approach an ETS/GETS service might *not* get 
> uniformly high admission priority treatment across 
> administrative domains (ADs), depending on how the policy 
> decision points (PDPs) in each AD decide to populate the RSVP 
> Admission Priority element.  Furthermore, my understanding is 
> that the PDP in each AD is expected to always key off the 
> Application Level Resource Priority (based on the SIP 
> resource priority header).  These are 2 major differences 
> with the qspec approach.  I presume, however, that the RSVP 
> admission priority approach is implemented (or planned to be 
> implemented) in real network applications.  It would be nice 
> to be enlightened RE implementations, existing or planned, if 
> possible.
>  
> A further suggestion is to re-name the RSVP approach <RSVP 
> Admission Priority> to distinguish it from <Y.2171 Admission 
> Priority>, so that neither approach should be considered a 
> 'generic' approach.
>  
> Barring any objection, I'll go ahead and modify the qspec 
> draft to rename <Admission Priority> to <Y.2171 Admission 
> Priority>, as agreed.
>  
> Jerry
> 
> 
> Gerald Ash <[email-masked]> wrote: 
> 
> 	All,
> 	 
> 	John writes in 
> http://www.ietf.org/mail-archive/web/nsis/current/msg08243.html:
> 	 
> 	John> Just some background history.  There are 3 
> documents defining similar
> 	John> fields
> 	John>
> 	John> tsvwg-emergency-rsvp 
> 	John> nsis-qspec 
> 	John> dime-qos-parameters
> 	John>
> 	John> We discussed this on this list and at previous 
> IETF meetings.
> 	John> My view of consensus was that...
> 	 
> 	I've seen no discussion on the list either before or 
> after the 'Proposed Resolution' was posted on 3 December at 
> http://www.ietf.org/mail-archive/web/nsis/current/msg08155.htm
> l 
> <http://www.ietf.org/mail-archive/web/nsis/current/msg08155.ht
> ml> .  This is just presented and not explained.  AFAICT no 
> co-authors of the QSPEC document participated actively in the 
> off-line discussion or explicitly agreed to the proposed 
> resolution.  So I don't see that there was any 'consensus'.
> 	 
> 	John> ... there should be some harmony and
> 	John> a common registry between these documents. 
> 	 
> 	The proposed resolution says:
> 	 
> 	"o Regarding Admission Priority:
> 	* every protocol spec will only indicate that "higher 
> value means higher priority".
> 	* there is no attempt to define what specific values 
> should be used for what. this is left outside the scope of 
> the protocol specs.
> 	* each protocol spec will add a statement clarifying 
> that a given Admission Priority is to be encoded with the 
> same value in each of the three protocol spec. For example, 
> in tsvwg-emergency-rsvp, under section 3.1. we will add:
> 	" A given Admission Priority is encoded in this 
> information element
> 	using the same value as when encoded in the Admission Priority
> 	parameter defined in section 6.2.9 of [nsis-qspec], or 
> in the Admission
> 	Priority parameter defined in section 4.10 of 
> [dime-qos-parameters].
> 	In other words, a given value in any of the 
> [emergency-rsvp] Admission
> 	Priority information element, the [nsis-qspec] 
> Admission Priority parameter
> 	or the [dime-qos-parameters] Admission Priority 
> parameter, refers to
> 	the same Admission Priority.
> 	"
> 	* the mirror statement will be added in nsis-qspec 
> (section 6.2.9) and dime-qos-parameters (section 4.10)"
> 	 
> 	The above proposed resolution is very unclear and does 
> not begin to explain that (apparently) what is proposed is to 
> drop the QSPEC approach to admission priority and replace it 
> with the emergency-rsvp approach.  
> 	 
> 	Admission priority is a well defined concept supporting 
> priority in flow admission control.  There are 3 priority 
> levels defined in QSPEC, following the agreement standardized 
> in Y.2171 http://www.itu.int/rec/T-REC-Y.2171/en.  The intent 
> is that 'high admission priority' is reserved for emergency 
> telecommunications.  'Normal admission priority' is reserved 
> for traffic that is not as critical as emergency 
> telecommunications but requires better than 'best effort 
> admission priority'.  Examples include real-time services 
> (VoIP, video), VPN and data services. 'Best effort admission' 
> priority is reserved for a broad class of traffic that can be 
> considered the lowest priority best effort flows.  Examples 
> include "traditional" ISP services (e-mail, web surfing). 
> 	 
> 	According to Francois (see 
> http://www.ietf.org/mail-archive/web/nsis/current/msg08251.htm
> l), the emergency-rsvp approach is something aligned with 
> preemption priority where no standard admission priority 
> values are standardized in a registry.  However preemption 
> priority works in a completely different way than admission 
> priority; there are 2 values; 'defending priority' and 
> 'preemption priority'.  These can be assigned somewhat 
> arbitrarily since only the *relative* values have 
> significance.  That is, the absolute values don't matter, it 
> is only the relative value that matters.  In this way 
> preemption can work across domains without standarding 
> absolute values of defending priority and preemption 
> priority.  It is unclear how such an approach can work for 
> admission priority since the decision to admit or not admit a 
> flow is done at the time of flow admission control and there 
> is no prior 'defending priority' assigned to a flow when it 
> first arrives for admission control.  So it unclear how the 
> emergency-rsvp approach is aligned with the preemption 
> priority approach.
> 	 
> 	According to Ken (see 
> http://www.ietf.org/mail-archive/web/nsis/current/msg08248.htm
> l), the emergency-rsvp approach involves using policy 
> elements, PDPs doing 'mappings', preemption, and namespaces.  
> AFAIK preemption priority doesn't have namespaces, and what 
> Ken describes looks different from what Francois describes.  
> 	 
> 	In any case it appears that emergency-rsvp is doing 
> something quite different from what QSPEC is doing.
> 	 
> 	John> I think wee need to be able to support a few 
> different scenarios and usages 
> 	John> for the admission priority.
> 	 
> 	I'm not sure what 'different scenarios' we're trying to 
> support here?  As discussed above, admission priority is a 
> well defined concept supporting priority in flow admission 
> control.  I've seen no mention of any other 'different 
> scenarios' for admission priority on the list.  Can you elaborate?
> 	 
> 	John> Is there a way that we could have a  common 
> structure to hold
> 	John> the values, and the ability to set the values accordingly?
> 	 
> 	Obviously one option is for emergency-rsvp to adopt the 
> approach being taken all along in QSPEC.  We are not being 
> told why this is not considered. 
> 
> 	Francois> Perhaps another option could be for the Qspec 
> document to state
> 	Francois> that the Admission Priority values MAY be set 
> according to Y.2171
> 	Francois> (but not mandate those are the only valid 
> assignment and not
> 	Francois> request creation of a Qspec-specific IANA 
> registry for those)?
> 	 
> 	This is essentially the same as the 'proposed 
> agreement', i.e. to drop the QSPEC approach to admission 
> priority and do away with standardized admission priority 
> values.  If we eliminate this standardization, then different 
> admission priority values can be assigned in different Admin 
> domains, and will have no end-to-end significance.  As such, 
> each Admin domain has no idea how to treat the flow admission 
> priority during flow admission since different domains are 
> using different encodings of admission priority.
> 	 
> 	IMO we should retain the standardized admission 
> priority levels as included in QSPEC for a long time.  If 
> emergency-rsvp cannot adopt the same approach, then for now 
> retain 2 approaches.
> 	 
> 	Jerry
> ________________________________
> 
> 	Never miss a thing. Make Yahoo your homepage. 
> <http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs>  
> 
> 
> ________________________________
> 
> Never miss a thing. Make Yahoo your homepage. 
> <http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs>  
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsis

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Fri, 07 Mar 2008 08:49:36 -0500

Martin:

QSPEC is not for ITU-T standard-specific QOS draft.

Only in Y.xxxx section MAY contain Y.xxx-specific admission priority.

However, QSPEC spec MUST include "General purpose" admission priority.

Is this clear to the group? Or, we we like to go for another cycles of emails for another year?

Best regards,
Radhika

----- Original Message -----
From: Martin Stiemerling 
Date: Friday, March 7, 2008 7:53
Subject: Re: [NSIS] Admission field in QSPEC -- was RE: Review ofdraft-ietf-nsis-qspec-18.txt
To: Gerald Ash 
Cc: nsis 

> However, there current approach elimantes the idea of having an 
> object understood by all participating partners (RSVP, NSIS, etc) 
> in terms of the admission priority.
> 
> The updated QSPEC will solely have the "Y.2171 Admission Priority" 
> but no general purpose admission priority (as in draft-ietf-tsvwg-
> emergency-rsvp). 
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria 
> Road, London W3 6BL | Registered in England 2832014 
> 
> > directly comparable with that in the QSPEC so as to avoid 
> confusion."> 
> > A further suggestion is to re-name the RSVP approach > > Admission Priority> to distinguish it from > > Priority>, so that neither approach should be considered a 
> > 'generic' approach.
> > 
> > draft to rename to > > Priority>, as agreed.
> > 
> > Jerry
> > 
> > 
> > Gerald Ash wrote: 
> > 
> > All,
> > 
> > John writes in

---

From: ken carlberg <[email-masked]>
Date: Fri, 7 Mar 2008 09:15:05 -0500

> purpose admission priority in the QSPEC?

Francois and I would feel comfortable with this approach as well.

-ken

---

From: Gerald Ash <[email-masked]>
Date: Fri, 7 Mar 2008 12:57:00 -0800 (PST)

Martin,
   
  > Thanks for your summary and the proposal to change the field.
   
  It wasn't my proposal, it was Ken's proposal who said that if adopted he would "be more than happy to drop the subject altogether."  However, it seems now that this agreement wasn't enough to drop the subject altogether after all.

> However, there current approach elimantes the idea of
  > having an object understood by all participating partners
  > (RSVP, NSIS, etc) in terms of the admission priority.
>
> The updated QSPEC will solely have the "Y.2171 Admission
  > Priority" but no general purpose admission priority (as in
  > draft-ietf-tsvwg-emergency-rsvp). 
   
  Note that the emergency-rsvp folks would prefer to call the rsvp admission priority "generic admission priority" (GAP).  The object used for GAP is as follows (see Section 3.1 of  http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-05.txt):
   
  3.1.  Admission Priority Policy Element 
    
   The format of the Admission Priority policy element is as follows: 
    
          0           0 0           1 1           2 2           3 
          0  . . .    7 8   . . .   5 6    . . .  3 4  . . .    1 
         +-------------+-------------+-------------+-------------+ 
         |     Length                | P-Type = ADMISSION_PRI    | 
         +-------------+-------------+-------------+-------------+ 
         | Flags       | M. Strategy | Error Code  | Reserved    | 
         +-------------+-------------+-------------+-------------+ 
         |              Reserved                   |Adm. Priority| 
         +---------------------------+---------------------------+ 

  This is an rsvp-specific object and if incorporated into qspec would lead to significant changes (probably also in qos-nslp).  IMO this would be a very bad approach.
  
> How about having the "Y.2171 Admission Priority" and the
  > general purpose admission priority in the QSPEC?
   
  A possible approach would be to add an L bit in the NSIS admission priority object, as follows (see Section 5.2.9 in http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-19.txt):
   
  5.2.9 <Admission Priority> Parameter [Y.2171]

   The coding for the <Admission Priority> parameter is as follows:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r|           9           |r|r|r|r|          1            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Admis.Priority|L|                (Reserved)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   High priority flows, normal priority flows, and best-effort priority
   flows can have access to resources depending on their admission
   priority value, as described in [Y.2171], as follows:

   Admission Priority:

   0 - best-effort priority flow
   1 - normal priority flow
   2 - high priority flow
   
     L bit:
   
     0 - admission priority field has end-to-end significance
         (above admission priority values in IANA registry apply)
     1 - admission priority field has local significance only
         (admission priority values set by local domain administrator)
   
  In order to have this understood by all participating partners, it would be best if emergency-rsvp would also adopt the L bit with the same semantics.
   
  It would be good to get some other opinions here, besides the 4 or 5 of us who have discussed this so far.
   
  Jerry

Martin Stiemerling <[email-masked]> wrote:
    Hi Jerry,

Thanks,

Martin

> A further suggestion is to re-name the RSVP approach > Admission Priority> to distinguish it from > Priority>, so that neither approach should be considered a 
> 'generic' approach.
> 
> draft to rename to > Priority>, as agreed.
> 
> Jerry

---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.

---

From: ken carlberg <[email-masked]>
Date: Sat, 8 Mar 2008 15:47:56 -0500

> It wasn't my proposal, it was Ken's proposal who said that if  
> adopted he would "be more than happy to drop the subject  
> altogether."  However, it seems now that this agreement wasn't  
> enough to drop the subject altogether after all.

my frustration with your input in the matter has made it all too  
tempting to wash my hands of the matter. however, I will not disregard  
input from calmer third parties.

> Note that the emergency-rsvp folks would prefer to call the rsvp  
> admission priority "generic admission priority" (GAP).  The object  
> used for GAP is as follows (see Section 3.1 of  http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-05.txt) 
> :

this has now gotten silly.  in a previous email you asked that we  
change the field to the "rsvp admission priority" and now you are  
asking that we change it to the "generic admission priority".  this  
really smells too much of If-I-have-to-change-it-so-you-have-to-change- 
it.  I stated quite clearly that the suggested name change stems from  
your explicitly tying the field to the Y.2171 document.  Which is  
consistent with what you did later in your document in Section 5.2.14  
concerning the Y.1541 QoS.  So please stop this tit-for-tat argument.

> A possible approach would be to add an L bit in the NSIS admission  
> priority object, as follows (see Section 5.2.9 in http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-19.txt) 
> :

well, one constructive thing would have been to start with a response  
why you feel Martin's idea above is not acceptable.  As for an "L"  
bit, I'll discuss this with James and Francois.  However, any reliance  
or dependency on Y.2171 as an exclusive authoritative source for  
values is probably not acceptable for RSVP draft.  I won't repeat why  
since that can be seen in the archives.

>    The coding for the <Admission Priority> parameter is as follows:

just for old times sake, I'll still be thrilled to hear what you will  
do if the ITU updates Y.2171 with a non-backwards compatible set of  
values.

> of us who have discussed this so far.

indeed.  I'd be quite interested to hear from the other co-authors of  
the QSPEC have to say.  I spoke briefly with James Polk about the  
matter and he is not in favor of tying the Admission Priority field in  
the RSVP draft to any output from the ITU.  (James is not on the NSIS  
list, hence his lack of direct input).

-ken

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 08 Mar 2008 17:40:49 -0600

Gerry

So, let me get this straight (from you), you are backing only an 
Admission priority indicator (a field) that travels only end2end or 
not at all (because that's the way "all SPs and vendors have agreed to")?

If true, you only see one of the following scenarios working

Scenario 1 - RSVP e2e
        +----------+   +----------+   +---------+   +---------+
        |   RSVP   |<->|   RSVP   |<->|  RSVP   |<->|  RSVP   |
        +----------+   +----------+   +---------+   +---------+
          Domain1        Domain2       Domain3        Domain4

Scenario 2 - RSVP start/end, NSIS somewhere in the middle
        +----------+   +----------+   +---------+   +---------+
        |   RSVP   |<->|   NSIS   |<->|  RSVP   |<->|  RSVP   |
        +----------+   +----------+   +---------+   +---------+
          Domain1        Domain2       Domain3        Domain4

Scenario 3 - RSVP start/end, NSIS as the middle
        +----------+   +----------+   +---------+   +---------+
        |   RSVP   |<->|   NSIS   |<->|  NSIS   |<->|  RSVP   |
        +----------+   +----------+   +---------+   +---------+
          Domain1        Domain2       Domain3        Domain4

Scenario 4 - NSIS start/end, RSVP as the middle
        +----------+   +----------+   +---------+   +---------+
        |   NSIS   |<->|   RSVP   |<->|  RSVP   |<->|  NSIS   |
        +----------+   +----------+   +---------+   +---------+
            Domain1        Domain2       Domain3        Domain4

Scenario 5 - NSIS start/end, RSVP somewhere in the middle
        +----------+   +----------+   +---------+   +---------+
        |   NSIS   |<->|   NSIS   |<->|  RSVP   |<->|  NSIS   |
        +----------+   +----------+   +---------+   +---------+
          Domain1        Domain2       Domain3        Domain4

Scenario 6 - NSIS e2e
        +----------+   +----------+   +---------+   +---------+
        |   NSIS   |<->|   NSIS   |<->|  NSIS   |<->|  NSIS   |
        +----------+   +----------+   +---------+   +---------+
            Domain1        Domain2       Domain3        Domain4

The only one you see working is scenario 6 because it is NSIS e2e.  I 
know this is the NSIS WG list, but do you believe it is realistic or 
idealistic to advocate (what seems like) a 
my-way-or-I-oppose-all-other-ways direction?

Shouldn't there be a means for interoperability without 100% 
comformance to 1 way of doing a thing?

Just looking for clarification with diagrams, so I can visualize what 
you're really saying.

James

At 02:57 PM 3/7/2008, Gerald Ash wrote:
>used for GAP is as follows (see Section 3.1 
>of 
><http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-05.txt>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-05.txt):
>
>This is an rsvp-specific object and if incorporated into qspec would 
>lead to significant changes (probably also in qos-nslp).  IMO this 
>would be a very bad approach.
>
>priority object, as follows (see Section 5.2.9 in 
><http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-19.txt>http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-19.txt):
>
>In order to have this understood by all participating partners, it 
>would be best if emergency-rsvp would also adopt the L bit with the 
>same semantics.
>
>object understood by all participating partners (RSVP, NSIS, etc) in 
>terms of the admission priority.
>
>but no general purpose admission priority (as in 
>NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, 
>London W3 6BL | Registered in England 2832014
>
> > A further suggestion is to re-name the RSVP approach > Admission 
> Priority> to distinguish it from > Priority>, so that neither 
> approach should be considered a
> > 'generic' approach.
> >
>Looking for last minute shopping deals? 
><http://us.rd.yahoo.com/evt=51734/*http://tools.search.yahoo.com/newsearch/category.php?category=shopping>Find 
>them fast with Yahoo! Search.

---

From: Gerald Ash <[email-masked]>
Date: Sun, 9 Mar 2008 10:51:23 -0700 (PDT)

James,
   
  Responses below.
   
> not at all (because that's the way "all SPs and vendors have agreed
   
  Hardly.  I don't think summaries like that help get to some conclusion/consensus here.  You need to go back and read the thread a little more carefully.  
   
  What I am 'backing' most recently is stated in my last post http://www.ietf.org/mail-archive/web/nsis/current/msg08279.html (in response to Martin's request to also accommodate the rsvp approach in nsis) proposed a way to accommodate both the rsvp approach and nsis approach by using an L bit to indicate:
   
     L = 0 - admission priority field has end-to-end significance
         (above admission priority values in IANA registry apply)
     L = 1 - admission priority field has local significance only
         (admission priority values set by local domain administrator)
   
  If both nsis and rsvp incorporate the L bit, then both approaches could be accommodated.
  
> If true, you only see one of the following scenarios working
   
  Hardly.  Again, your phrasing leaves a lot to be desired here.
  
> Just looking for clarification with diagrams, so I can visualize what 
   
  All the above scenarios 1 --> 6 would work if both rsvp and nsis incorporated the L bit, as proposed.  Once again, that proposal is to accommodate *both* approaches, as suggested by Martin.  If people have alternative proposals, please go ahead and make them.
   
  Jerry

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 09 Mar 2008 15:27:26 -0500

Gerry

I read the 'L-bit' idea before I commented and I have problems with 
it.  In any of the 6 scenarios listed below, when is it appropriate 
to use L = 1? In other words, when does the reservation signaling 
protocol not believe it is the only one in use, and what difference 
would it make it is was or wasn't?

I'm suggesting that 'translation' makes the signaling at any stage of 
any scenario make everything look e2e (L=0), which makes L=1 rather 
pointless, I believe.

Now, if there was a trusted indication that informs all reservation 
protocols along a signaling path that there was no reservation 
protocol used within a part of the e2e path, that would be useful, I 
think - but that's not what you are suggesting.

James

At 12:51 PM 3/9/2008, Gerald Ash wrote:
>Hardly.  I don't think summaries like that help get to some 
>conclusion/consensus here.  You need to go back and read the thread 
>a little more carefully.
>
>What I am 'backing' most recently is stated in my last post 
><http://www.ietf.org/mail-archive/web/nsis/current/msg08279.html>http://www.ietf.org/mail-archive/web/nsis/current/msg08279.html 
>(in response to Martin's request to also accommodate the rsvp 
>approach in nsis) proposed a way to accommodate both the rsvp 
>approach and nsis approach by using an L bit to indicate:
>
>All the above scenarios 1 --> 6 would work if both rsvp and nsis 
>incorporated the L bit, as proposed.  Once again, that proposal is 
>to accommodate *both* approaches, as suggested by Martin.  If people 
>have alternative proposals, please go ahead and make them.
>
>Jerry
>
> >
> > James
> >
>
>
>Never miss a thing. 
><http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs>Make 
>Yahoo your homepage.

---

From: Gerald Ash <[email-masked]>
Date: Sun, 9 Mar 2008 15:51:47 -0700 (PDT)

James,
   
  > I read the 'L-bit' idea before I commented and I have
  > problems with it.  In any of the 6 scenarios listed below,
  > when is it appropriate to use L = 1? In other words, when
  > does the reservation signaling protocol not believe it is
  > the only one in use, and what difference would it make it
  > is was or wasn't?
> 
> I'm suggesting that 'translation' makes the signaling at
  > any stage of any scenario make everything look e2e (L=0),
  > which makes L=1 rather pointless, I believe.
> 
> Now, if there was a trusted indication that informs all 
  > reservation protocols along a signaling path that there
  > was no reservation protocol used within a part of the e2e
  > path, that would be useful, I think - but that's not what
  > you are suggesting.
   
  Martin suggested to incorporate the rsvp object (Admission Priority Policy Element) into nsis.  Rather than do that explicitly (I think there are other problems with that), I suggested what IMO is an equivalent approach.
   
  I don't see the problem with setting either L=0 or L=1 assuming that both rsvp and nsis incorporate the L bit into their respective objects.  As for your scenarios:

  If domain1 sets L=1, then domain2, domain3, and domain4 all set L=1 meaning that the admission priority values only have local significance (as per the rsvp design).
   
  If domain1 sets L=0, then domain2, domain3, and domain4 all set L=0 meaning that the admission priority values have e2e significance according to the IANA registry (as per the nsis design).

  If domain1 sets L=1, then domain2, domain3, and domain4 all set L=1 meaning that the admission priority values only have local significance (as per the rsvp design).
   
  If domain1 sets L=0, then domain2, domain3, and domain4 all set L=0 meaning that the admission priority values have e2e significance according to the IANA registry (as per the nsis design).
   
  I don't see the problem with the approach.  I think it satisfies Martin's request.  However, anyone else is more than welcome to propose an alternative.
   
  Jerry

---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  Try it now.