Subject: Re: RFC 2515: Parent VPLs for cross-connected child VCLs

From: Kaj Tesink <[email-masked]>
Date: Wed, 23 May 2001 16:15:08 -0400

Hi Umberto,

At 05:41 PM 5/23/01 +1000, you wrote:
>Hi Kaj,
>a quick question for you :-)
>
>You recall that RFC 2515 states that for atmVplTable
>"Entries are not present in this table for
>the VPIs used by entries in the atmVclTable."
>which was different from the old RFC 1695 interpretation.

wellllll, the issue with 1695 was that there were two different
interpretations. the current 2515 interpretation was the more
common one and therefore founds its way into 2515.

>My two-part question is:
>Q1.1) Can you go ahead anyway and create the parent VPL entry for a
>cross-connected VCL
>where they do share the same VPI?
>Why do this?
>Well, a) I want to set the traffic params on the parent VPL so we
>can feed that to, say, a VP-aggregate traffic shaper queue.
>b) You can also do a VP-loopback test on the parent VPL using the
>forthcoming ATM-TEST-MIB.
>In your answer to Christian, attached below [:-)],
>you state:
>"you dont - it may be difficult to correlate separate traffic param sets for
>a
>VCC and for the underlying VPL anyway. however, if you really want to do
>this then you would have to configure separate VPL and VCL entries."

the key argument here was for simplicity over complexity.

>Q1.2) Does that mean that a conforming implementation to RFC 2515 can still
>accept
>entries for atmVplTable even though these VPLs have child cross-connected
>VCLs?
>In other words "Entries are not present in this table for the VPIs used ..."
>as per RFC 2515 means that the presence of same VPI parent VPL's isn't
>strictly banned
>but instead the presence of same VPI parent VPL's is just optional when they
>have
>child cross-connected VCL's ???

there are two issues:
- conformance to rfc2515; i dont think there would be a big problem here
   since you dont seem to break any minimal implementation rules
- conformance to how rfc2515 is used (i.e., by a NMS)
   this may be a problem. if you automate e.g., a vcl establishment process
   under a button (e.g., see 
http://www.simple-times.org/pub/simple-times/issues/3-2.html
   for a dated reference) then this process would depend
   on the interpretation you describe above. this may be ok in vendor-specific
   solutions but may break in multi-vendor arrangements.

and of course there would still be the complexity argument, e.g., correlation
of vpl and vcl traffic parameters, but assuming you figure that out this would
not be a conformance issue

kaj

>Yours Sincerely,
>
>Umberto Bonollo ([email-masked])
>Senior Computer Scientist
>ATM Projects
>Systems Software Department
>NEC Australia
>
>P.S. feel free to copy your answer to the ATOMMIB group.
>
>-----Original Message-----
>From: Kaj Tesink [mailto:[email-masked]]
>Sent: Tuesday, 12 January 1999 3:43
>To: Lochum Christian (NTC/Dusseld); AToMdiscus
>Subject: Re: questions to RFC1695
>
>
>Christian,
>
>the short answers:
>1) yes, the interpretation has changed
>2) i'm confused on the question
>see annotations below
>
>kaj
>
>------------------------------------------
>
>At 01:45 PM 1/11/99 +0200, Lochum Christian (NTC/Dusseld) wrote:
> >Hello,
> >
> >I am SW designer and I have some questions regarding the interpretation of
> >the standard. I tryed to follow the archive, but even there I didn't find
> >the answer. I tryed to look at existing implementation and I even thought
> >they are wrong.
> >
> >It would be realy helpful, if you could find the time to answer these
> >questions.
> >So here are the question:
> >
> >1) Do I have to create an entry in the atmVplTable, before I can create an
> >entry in the atmVclTable with the same VPI value?
> >For example, if I want to terminate a single VCC, which is transported
> >inside a VPC, that also is terminated inside my node.
> >Do I have to create an entry at the atmVclTable and atmVplTable?
> >
> >In the Simple Times from august 1994 Volume 3, Number 2 Kaj Tesink wrote:
> >"This article illustrates [..] the configuration of a VCC between hostA and
> >hostB through on ISS. It assumes that the underlying VPLs are established."
> >
> >But in the new draft-ietf-atommib-atm1ng-06.txt it is defined:
> >
> > atmVplTable         OBJECT-TYPE
> >                    SYNTAX         SEQUENCE OF AtmVplEntry
> >                    MAX-ACCESS     not-accessible
> >                    STATUS         current
> >                    DESCRIPTION
> >                     "The Virtual Path Link (VPL) table.  A
> >                      bi-directional VPL is modeled as one entry
> >                      in this table. This table can be used for
> >                      PVCs, SVCs and Soft PVCs.
> >                      Entries are not present in this table for
> >          the VPIs used by entries in the atmVclTable."
> >
> >                    ::= { atmMIBObjects 6}
> >
> >I think the interpretation has changed and I will only create an Entry for
> >the VCC.
> >Is this right?
>
>yes that is correct
>
> >
> >But, if you model it this way. How do you give the traffic params for the
> >VPL?
>
>you dont - it may be difficult to correlate separate traffic param sets for
>a
>VCC and for the underlying VPL anyway. however, if you really want to do
>this then you would have to configure separate VPL and VCL entries.
>
> >
> >2) If an entry is created in the atmVplTable and it is not cross connected
> >is has an adminStatus, but if I later cross- connect this entry to another
> >Vpl the adminStatus vanishes.
> >But how is than the operStatus be invluenced. Should it follow the
> >adminStatus of the according atmVpCrossConnection?
>
>my confusion is perhaps the relationship with 1) (if any).
>if you use the VPL to support a VCL that is crossconnected in the next node
>you can not also start crossconnecting that VPL in the same node.
>
>
> >
> >Best regards
> >
> >Christian van Lochum
> >
>
>
>
>
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
>Kaj Tesink
>Bellcore
>Email  [email-masked]
>Tel    732.758.5254
>Fax    732.758.2269
>Postal 331 Newman Springs Rd
>        Red Bank, NJ 07701
>        USA
>
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies
Email  [email-masked]
Tel    732.758.5254
Fax    732.758.2269
Postal 331 Newman Springs Rd
        Red Bank, NJ 07701
        USA

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

---

From: "Umberto Bonollo" <[email-masked]>
Date: Thu, 24 May 2001 11:42:16 +1000

Hi Kaj,
Thanks for your thoughtful input on this one.

First, I wanted to acknowledge your complexity argument.

Also, it follows then with respect to a multivendor environment that
it's possible that a strict agent might reject VxL (VL) establishment by
checking whether the parent/child entry was present in
the other table.
So the safest solution from an NMS usage viewpoint in a multivendor
environment is
to assume that the target agent conforms strictly to RFC 2515 advice i.e.
"Entries are not present in this table for
the VPIs used by entries in the atmVclTable."

Umberto

-----Original Message-----
From: Kaj Tesink [mailto:[email-masked]]
Sent: Thursday, 24 May 2001 6:15
To: Umberto Bonollo
Cc: [email-masked]
Subject: Re: RFC 2515: Parent VPLs for cross-connected child VCLs

Hi Umberto,

there are two issues:
   on the interpretation you describe above. this may be ok in
vendor-specific

and of course there would still be the complexity argument, e.g.,
correlation
of vpl and vcl traffic parameters, but assuming you figure that out this
would
not be a conformance issue

kaj

Kaj Tesink
Telcordia Technologies

---

From: Kaj Tesink <[email-masked]>
Date: Tue, 29 May 2001 11:29:34 -0400

>the VPIs used by entries in the atmVclTable."

yep, minimal assumptions always seem to be a safe way to go

kaj

Kaj Tesink
Telcordia Technologies