Subject: RE: [NSIS] GIST extensibility concern (IANA considerations)

From: <[email-masked]>
Date: Mon, 6 Mar 2006 13:24:53 +0200

Catching up ...

>a quick comment on the message type/protocol id/mrm aspects.
>
>i think there are actually two aspects here:
>- whether GIST can cope (in some sense) with new protocol
>  numbers
>- whether experimental numbers are useful
>
>we have to be able to do the first, whether the new protocol 
>number comes because of an experiment or some other official 
>assignment. In the three cases mentioned, I think the spec is
>ok:
>- unknown message types are rejected with an error (don't
>  change subsequent processing)
>- unknown protocol IDs are ignored (when deciding what type
>  of MA to build)

Agreed

>the case of an unknown MRM is slightly more subtle; it was 
>discussed in the thread starting here 
>http://www1.ietf.org/mail-archive/web/nsis/current/msg05367.html
>the upshot is that you should only get experimental MRMs with 
>experimental NSLPs; and if you don't support the experimental 
>NSLP you ignore the MRM. 
>
>so I think that experimental values for these are safe in the 
>sense that unknown values are handled correctly.

I agree.  I think that experimental MRMs are needed for testing
in a local environment.

>of course, they are not safe if people adopt conflicting 
>definitions of the unknown values. so the only environment in 
>which valid experiments can be done is some sort of 
>closed/private one (i.e.
>one in which the experimenter knows all the experiments that 
>are in progress). i think this is (implicitly) the type of 
>experiment that rfc3692 is talking about. I still think it's 
>useful to have an assignment range for that type of 
>experiment, because it guarantees that some kind of software 
>upgrade that brings in non- experimental new protocol numbers 
>(e.g. because of some other standards work or expert review) 
>will not suddenly cause a collision. it's a not very 
>sophisticated mechanism for a not very ambitious goal.

Agreed - that is the idea of 3692, or at least my reading of it.

>it may be that the IANA section (whatever else we do with it) 
>should be more explicit about what 'private/experimental' 
>means, including possibly a reference to 3692. i'd like not to 
>ban experiments, especially in the protocol ID and MRM cases, 
>because actually I can think of some very interesting 
>experiments to do there.

Agreed.

>cheers,
>
>r.
>
>> -----Original Message-----
>> From: Henning Schulzrinne [mailto:[email-masked]]
>> Sent: 15 February 2006 14:32
>> To: [email-masked]
>> Cc: Hancock, Robert; [email-masked]
>> Subject: Re: [NSIS] GIST extensibility concern (IANA considerations)
>> 
>> 
>> John,
>> 
>> Let me try to make some suggestions:
>> 
>> NSLP Identifier:
>>    Seems likely to need experiments and there's a 
>pretty-well defined 
>> mechanism for ignoring unknown NSLPs. I would suggest an escape code 
>> and a new TLV field. One possibility that avoids registration is to 
>> use a UUID, which is 128 bits. See RFC 4122 for the text version. An 
>> alternative is to use the enterprise codes and an 
>enterprise-specific 
>> number (say, 16 bits). See
>> http://www.iana.org/assignments/enterprise-
>> numbers  This would be a total of 48 bits, assuming 32 bits are long 
>> enough for an enterprise number.
>> 
>> GIST Message Type:
>>    Seems less likely to need experiments and experiments seem more 
>> dangerous, as it is unclear how well nodes that don't understand 
>> message types can deal with them. I would suggest dropping private/ 
>> experimental use, given that there is an expert review space that 
>> should make getting an identifier reasonably easy.
>> 
>> Object Types:
>>    Similar to NSLP identifier. Define an extension object 
>that always 
>> starts with a UUID or the enterprise code/type.
>> 
>> Message Routing Methods:
>>    Again, experiments seem likely to be disruptive. What do 
>I do with 
>> an unknown MRI? Thus, I'd suggest dropping the experimental range.
>> 
>> MA-Protocol-ID
>>    same
>> 
>> I think a basic issue is as to how well a system can deal 
>with unknown 
>> values. In some cases, it can, at best, generate an error and 
>> terminate the flow of GIST messages. In others, such as the NSLP 
>> identifier, it can ignore the value.
>> 
>> Is this a bit less vague?
>> 
>> Henning
>> 
>> 
>> On Feb 15, 2006, at 2:42 AM, <[email-masked]> wrote:
>> 
>> > Hi Henning,
>> >
>> > Its unclear what kind of extensibility you'd like and the usage 
>> > model of the extensiblity.  If you had a more concrete 
>proposal, it 
>> > might be easier to follow.
>> >
>> > I'm basically following the extensibility model proposed 
>in rfc3692.  
>> > Also, I think that GIST will be a more 'standard'
>> > transport protocol, where open extesibility is discouraged (as in 
>> > TCP, SCTP, DCCP, etc).
>> >
>> > John
>> >>>
>> 
>

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Robert Hancock" <[email-masked]>
Date: Sun, 19 Mar 2006 09:43:26 -0600

Hi,

I reviewed the QoS-NSLP on the flight yesterday and the above
question occurred to me about half-way across. 

We introduced stacking [see below for historical background] as
a means for accommodating localisation of the QoS specification
within particular domains. I think that's still a legitimate 
goal. However, the specification now has another way to achieve
the same thing, namely by creating a local signalling session
and using the BOUND_SESSION_ID to correlate the two at the edges,
with the e2e session ignored in the interior. 

I don't think it would take much work to eliminate the concept from
the qos-nslp (I haven't checked the qspec yet). And I'm sure there
would be tears of joy in some quarters.

r.

Background:
For a trip down memory lane, check out section 4.4 of
http://www.watersprings.org/pub/id/draft-hancock-nsis-framework-00.txt
(from 2002...). At the time, the main advantage of the stacking
approach was that domain boundary nodes could do all their processing
on a single message rather than having to correlate messages of 
multiple sessions. However, it now turns out that we can't avoid
that type of complexity for other reasons, including
- any sort of aggregation (where you have to handle 1+N messages)
- where the interior session needs uses different GIST transport
  characteristics (RMD)
- where it is natural to hide the e2e session in the interior
  (tunnel e.g. for mobility/vpn scenarios)
Given that session correlation is needed in all these other cases,
the advantage of being able to do without it in a particular case
basically vanishes. It's probably simpler to use a single mechanism
to handle everything.

---

From: <[email-masked]>
Date: Sun, 19 Mar 2006 18:21:02 +0200

Robert,

Your suggestion seems like a very good simplification.  I guess we 
would need some text, but how do others feel. I think this would
make the QoS NSLP a good deal simpler.

Comments?
John 

>From: ext Robert Hancock [mailto:[email-masked]] 
>Sent: 19 March, 2006 17:43
>To: [email-masked]
>Subject: [NSIS] Can we do without Q-spec stacking?
>
>Hi,
>
>We introduced stacking [see below for historical background] 
>as a means for accommodating localisation of the QoS 
>specification within particular domains. I think that's still 
>a legitimate goal. However, the specification now has another 
>way to achieve the same thing, namely by creating a local 
>signalling session and using the BOUND_SESSION_ID to correlate 
>the two at the edges, with the e2e session ignored in the interior. 
>
>I don't think it would take much work to eliminate the concept 
>from the qos-nslp (I haven't checked the qspec yet). And I'm 
>sure there would be tears of joy in some quarters.
>
>r.
>
>Background:
>(from 2002...). At the time, the main advantage of the 
>stacking approach was that domain boundary nodes could do all 
>their processing on a single message rather than having to 
>correlate messages of multiple sessions. However, it now turns 
>out that we can't avoid that type of complexity for other 
>reasons, including
>  (tunnel e.g. for mobility/vpn scenarios) Given that session 
>correlation is needed in all these other cases, the advantage 
>of being able to do without it in a particular case basically 
>vanishes. It's probably simpler to use a single mechanism to 
>handle everything.
>
>

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Sun, 19 Mar 2006 10:35:41 -0600

The QSPEC I-D assumes a stack of 2 QSPECs can be used in a local domain.
If the BOUND_SESSION_ID provides equivalent functionality, that would be
OK but we need to verify the details.

Jerry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, March 19, 2006 11:21 AM
To: [email-masked]; [email-masked]
Subject: RE: [NSIS] Can we do without Q-spec stacking?

Robert,

Comments?
John

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sun, 19 Mar 2006 21:06:14 +0100 (MET)

Hi Robert

This feature can be considered as a main feature that can be used
to increase the support of different QoS models on the same end-to-end
path.
Long time ago we agreed to use this feature, which is already extensively
used by some QoS models.

Therefore I am not in favour of removing this feature from the QoS-NSLP
draft

Best Regards,
Georgios

---

From: Jukka MJ Manner <[email-masked]>
Date: Sun, 19 Mar 2006 23:05:40 +0200 (EET)

Hi Rob,

I really don't see how life would be so much more fun with a single QSPEC
allowed. The stacking of two QSPECs is a good idea, quite simple to
implement the processing for it, and has shown to have support for a long
time. To support the stacking through implementing a separate
domain-internal session concept, and the processing for it would be a
number of times more complex and time consuming. If one wants to implement
the same functionality to stacking through a separate session, he is free
to do so.

Jukka

---

From: "Robert Hancock" <[email-masked]>
Date: Mon, 20 Mar 2006 07:31:15 -0600

jukka,

> number of times more complex and time consuming.

how is it more complex than what the draft already states or implies
is needed for aggregation and tunnel operation (and all the other
session binding scenarios)?

> If one wants to implement
> the same functionality to stacking through a separate 
> session, he is free to do so.

what I am questioning is that it seems we could have a choice 
between:
a) implement something complex for cases A-Y and simple for case Z
b) implement something complex for cases A-Z
Which of (a) or (b) leads to a simpler protocol?

r.

(leaving aside of course the question of whether stacking is really
simple, on which other people have much stronger views than me.)

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 20 Mar 2006 15:50:26 +0200 (EET)

Hi,

So, your idea is that since one anyway implements session binding and
tunneling, then stacking comes along "free". What if one doesn't implement
the binding and aggregation at all in his routers because the domain only
needs the simple stacking functionality, i.e., use a different QOSM within 
the domain?

Jukka

---

From: David R Oran <[email-masked]>
Date: Wed, 29 Mar 2006 07:47:59 -0500

> make the QoS NSLP a good deal simpler.
I think you might be able to predict where I'd come down on this  
design question :-)