Subject: RE: [NSIS] New NSIS-related drafts - L2 issue

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 16 Oct 2002 16:31:13 +0200

Bob Braden wrote>
> ...L2 properties may 
> have a place in the general signaling regime (which *I* think 
> is what the present NSIS WG should be addressing, not just a 
> particular subset such as QoS).

Do you have a preference how to continue on L2 issues?
Assuming a single basic NSIS signaling protocol supporting 
different NSIS client protocols NSIS could:

- Have a separate NSIS client protocol taking care of L2 
  related signaling
- Insert L2 stuff into other NSIS client protocols (like 
  QoS, may be others too)

I'd prefer the first attempt. The NSIS signaling 
transport protocol is IP however. So this would be
limited to L2 services with an IP control plane.

This would leave us with insertion into other client 
protocols as a solution. If support of L2 information is 
no more than an option, I think I could live with it. 
By "option" I mean:
- A NSIS client protocols progress to standard is not 
  delayed by the specification state of its L2 information 
  elements. 
- The L2 TLV(s) may be present in a signaling dialogue,
  but don't have to be.

I favour to keep interworking and service mapping issues 
out of signalling specifications.

Regards, Rüdiger

Rüdiger Geib>*> 
>*> Further, there's a parameter "L2 properties". It should 
>*> be removed without replacement. Layer 2 issues are 
>*> opaque to NSIS signalling. A network operator learns 
>*> which service is required by NSIS signaling. The
>*> operator then decides whether his network meets these service
>*> requirements or whether it doesn't. If NSIS signaling 
>*> will contain a Layer 2 specific service descriptor 
>*> combining every possible layer 2 with every possible 
>*> interpretation of service mapping per operator, we
>*> don't need NSIS. by the way, didn't we agree to limit 
>*> NSIS strictly to layer 3?
>  
Bob Braden> 
> I would suggest that this issue needs more thought.  I can tell you
> that our ATM friends are adding a whole new object class to RSVP[-TE]
> to carry one 3-bit integer encoding the ATM Qos class -- CBR, etc.  I
> know because the IANA asked me as RSVP expert to comment on the
> assignment of an RSVP class number.  I think that this particular
> extension is severely brain-dead; it should rather be a single CType
> for an L2 properties object (or be in a flowspec).  Unfortunately this
> work, like a lot of the stuff going on now, is outside the IETF so I
> have no say.  However, it does show that L2 properties may 
> have a place in the general signaling regime (which *I* think 
> is what the present NSIS WG should be addressing, not just a 
> particular subset such as QoS).
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Bob Braden <[email-masked]>
Date: Thu, 24 Oct 2002 18:09:29 GMT

*> 
  *> Bob Braden wrote>
  *> > ...L2 properties may=20
  *> > have a place in the general signaling regime (which *I* think=20
  *> > is what the present NSIS WG should be addressing, not just a=20
  *> > particular subset such as QoS).
  *> 
  *> Do you have a preference how to continue on L2 issues?  Assuming a
  *> single basic NSIS signaling protocol supporting different NSIS client
  *> protocols NSIS could:
  *> 
  *> - Have a separate NSIS client protocol taking care of L2=20
  *>   related signaling
  *> 
  *> - Insert L2 stuff into other NSIS client protocols (like=20
  *>   QoS, may be others too)
  *> 
  *> I'd prefer the first attempt. The NSIS signaling transport protocol is
  *> IP however. So this would be limited to L2 services with an IP control
  *> plane.
  *> 
  *> This would leave us with insertion into other client protocols as a
  *> solution. If support of L2 information is no more than an option, I
  *> think I could live with it.  By "option" I mean:
  *> 
  *> - A NSIS client protocols progress to standard is not=20
  *>   delayed by the specification state of its L2 information=20
  *>   elements.=20
  *> 
  *> - The L2 TLV(s) may be present in a signaling dialogue,
  *>   but don't have to be.
  *> 
  *> I favour to keep interworking and service mapping issues=20
  *> out of signalling specifications.
  *> 
  *> Regards, R=FCdiger
  *> 

Rudiger,

You raise hard questions and I don't know the answers.  As IANA expert
on RSVP registration, I currently know of four separate requests for
RSVP extensions, some of which are L2 specific.  One extension defines
a new object to carry two bits that are telephony-related; another
defines a new option to carry 3 bits (the ATM service class).  We must
expect that NSIS will run into even more severe complexity explosion
unless we figure out how to abstract this issue.

Bob Braden

  *> =20
  *> R=FCdiger Geib>*>=20
  *> >*> Further, there's a parameter "L2 properties". It should=20
  *> >*> be removed without replacement. Layer 2 issues are=20
  *> >*> opaque to NSIS signalling. A network operator learns=20
  *> >*> which service is required by NSIS signaling. The
  *> >*> operator then decides whether his network meets these service
  *> >*> requirements or whether it doesn't. If NSIS signaling=20
  *> >*> will contain a Layer 2 specific service descriptor=20
  *> >*> combining every possible layer 2 with every possible=20
  *> >*> interpretation of service mapping per operator, we
  *> >*> don't need NSIS. by the way, didn't we agree to limit=20
  *> >*> NSIS strictly to layer 3?
  *> > =20
  *> Bob Braden>=20
  *> > I would suggest that this issue needs more thought.  I can tell you
  *> > that our ATM friends are adding a whole new object class to RSVP[-TE]
  *> > to carry one 3-bit integer encoding the ATM Qos class -- CBR, etc.  I
  *> > know because the IANA asked me as RSVP expert to comment on the
  *> > assignment of an RSVP class number.  I think that this particular
  *> > extension is severely brain-dead; it should rather be a single CType
  *> > for an L2 properties object (or be in a flowspec).  Unfortunately this
  *> > work, like a lot of the stuff going on now, is outside the IETF so I
  *> > have no say.  However, it does show that L2 properties may=20
  *> > have a place in the general signaling regime (which *I* think=20
  *> > is what the present NSIS WG should be addressing, not just a=20
  *> > particular subset such as QoS).
  *> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 25 Oct 2002 08:54:14 +0200

Bob,

thanks for your reply. One more point I'd like to add: Obviously end 
to end signaling messages and the related data flows will cross a 
variety of different layer two technologies. If NSIS allows for L2
specific information, it will have to define where it is added for 
which L2, and who's allowed to add (and discard) it.
I'm interested in a simple and stable signaling protocol to start
with. I'd appreciate if NSIS tried to work out that, before it 
specifies more complex solutions.
 
Regrads