Subject: Re: Question on ATM MIB

From: Kaj Tesink <[email-masked]>
Date: Thu, 09 Apr 1998 15:47:00 -0400

Don,

I am less familiar with Annex 8; however, I am inclined
to agree with this since it would avoid
opening up this document later on just to expand the VP range
to include 0. However, as per Mickey's observation
any other enhancements to accommodate Annex 8 would
not be subject of this RFC but may be worked elsewhere
(atm3 or enterprise-specific)

Any other opinions on this from the list?

kaj

PS Don, can you send me the precise tile/date/reference of annex 8?

At 01:19 PM 4/9/98 -0400, [email-masked] wrote:
>
>
>
>
>Mickey, Kaj,
>
>Thanks for the quick replies.  I have no problem moving this to the public
>mailing list, but I don't currently subscribe to any list.  Is this list
>you are referring to the one on the IETF web page called
>"[email-masked]"?
>
>To answer your questions:
>
>1. Yes, an entry in the VPL table is required before making a VP cross
>connect.  A VP MUX can be thought of as an ATM switch that places limits on
>which ports VP cross connects can be made.  VPCs are allowed from any user
>port to any network port, but not between two user ports or between to
>network ports.  In fact, we implement our VP MUX product using a commercial
>ATM switch fabric that is capable of doing any port to any port switching,
>but we limit the switching in software.  I believe that the ATM MIB is
>appropriate for a VP MUX and the market is asking this feature in our VP
>MUX product.
>
>2. I understand your concerns with the VPCI/VPI mappings in the switch.
>However, if the wording in the MIB clearly states that VPI=0 is only valid
>for a VP MUX that implements Annex 8, at least this product can be
>supported by the ATM MIB.  Would it be possible to put a disclaimer
>somewhere in the RFC which states that Annex 8 is not fully supported for a
>switch?  Also, if a switch vendor chooses to support Annex 8, it is
>possible to implement an enterprise MIB with the required VPCI/VPI mapping.
>
>Don
>
>
>
>
>[email-masked] on 04/08/98 07:29:36 PM
>
>To:   [email-masked], Don Cantwell/US/3Com
>cc:   [email-masked], [email-masked]
>Subject:  Re: Question on ATM MIB
>
>
>
>
>At 12:38 PM 4/8/98 -0700, Mickey Spiegel wrote:
>>Don,
>>
>>> I have a question about the definition of a VPI value in the ATM MIB as
>>> defined in RFC1695 and in the internet draft "Definitions of Textual
>>> Conventions and OBJECT_IDENTITIES for ATM Management".  Both of these
>>> documents do not allow a VPI value of 0 in the VPL table or the VPC
>table.
>>>
>>> I'm working on a product that implements "Annex 8: Virtual UNIs" of ATM
>>> Forum UNI 4.0.  I'm adding support for RFC1695 to an existing product
>that
>>> implements Annex 8.  Annex 8 shows examples of virtual path connections
>>> using VPI 0 on the user side of a VPI MUX and this is what has been
>>> implemented in our product.  Our default configuration uses VPI=0 for
>all
>>> user ports.  When I add RFC1695 to this product, our default
>configuration
>>> is invalid under that RFC because it does not allow a VPI value of 0 in
>the
>>> VPL and VPC tables.  This seems to be inconsistent with Annex 8.
>>>
>>> I believe that a VPI value of 0 for a VPC should be allowed for products
>>> that implement Annex 8 of ATM Forum 4.0.  Can wording be added to the
>>> internet draft referenced above that allows a VPI value of 0 for
>products
>>> that implement Annex 8?
>>
>>I can think of a couple of issues with regard to supporting the
>>Virtual UNI functionality in these MIBs.
>>
>>1. Would you have to establish a VPL in the atmVplTable before creating
>>   the VP cross-connect?  or not?

>>
>>2. Your proposal would take care of configuration of the VP mux in the
>>   middle.  However, it does not cover the extra functionality needed at
>>   the ATM switch where the VPC terminates.  This ATM switch must code
>>   a VPCI of zero in its signalling messages, even though the VPI at the
>>   switch is non-zero.  We don't have any objects to configure either
>>   (a) a VP tunnel as a virtual UNI, or (b) VPI/VPCI mappings.  I would
>>   prefer option (b), but then we have to look ahead to the more general
>>   issue of one VP controlling other VPs.
>>
>>This sounds like a new feature.  We agreed not to work on additional new
>>features for this round of internet drafts.  We need to get these out,
>>then concentrate on the next round of updates (any UNI 4.0/PNNI 1.0
>>functionality that we have not already covered).
>I agree with all points that Mickey points out. However,
>as I have been editing the 1695ng yesterday nite
>it occurred to me that we may want to include the 0 value
>so as not to upset future extensions?
>>
>>Mickey
>>
>>P.S. Perhaps we should move this thread over to the atommib mailing list.
>>     I have no problem with any of the above appearing on the public list.
>i agree too - just am not sure whether Don considers his info as
>proprietary
>>
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>_/                                                                      _/
>_/  Kaj Tesink                                                          _/
>_/  Bellcore                                                            _/
>_/  Business Internet Professional Services  vmail (732) 758-5254       _/
>_/  331 Newman Springs Rd.                   email [email-masked]  _/
>_/  Red Bank, NJ 07701                     faxmail (732) 758-2269       _/
>_/                                                                      _/
>_/  * NOTE AREA CODE CHANGE (908) --> (732) EFFECTIVE JUNE 1, 1997 *    _/
>_/                                                                      _/
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> 

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/                                                                      _/
_/  Kaj Tesink                                                          _/
_/  Bellcore                                                            _/
_/  Business Internet Professional Services  vmail (732) 758-5254       _/
_/  331 Newman Springs Rd.                   email [email-masked]  _/
_/  Red Bank, NJ 07701                     faxmail (732) 758-2269       _/
_/                                                                      _/
_/  * NOTE AREA CODE CHANGE (908) --> (732) EFFECTIVE JUNE 1, 1997 *    _/
_/                                                                      _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

---

From: Gary Hanson <[email-masked]>
Date: Thu, 9 Apr 1998 15:08:06 -0700 (PDT)

Kaj,

> Any other opinions on this from the list?

I agree that a VPC may very well be desired on VPI 0, and I see
this as a very natural evolution of an object to allow support
for such cases.  Since atmVplVpi has been re-defined to have a
textual convention SYNTAX of AtmVpIdentifier, which allows the
full range of 0..4095, this evolution from RFC 1695 has already
occurred in <draft-ietf-atommib-atm1ng-02.txt>, and I do fully
support it.

I would go further, and also modify the compliance statement
for ATM UNIs to allow the full range of 0..255 instead of just
1..255 as it is currently written in that draft.

Regards,
Gary