[mpls] FW: poll on draft-vkst-mpls-tp-te-mib-00.txt

[Eric Gray <[e-mail]>]

Forwarding in plain text...

________________________________

From: Thomas D. Nadeau [mailto:[e-mail]]
Sent: Thursday, June 16, 2011 1:19 PM
To: Joan Cucchiara; [e-mail]; 'venkatesan mahalingam'; 'mpls'
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: poll on draft-vkst-mpls-tp-te-mib-00.txt





Joan Cucchiara On 6/16/11 1:17 PM, "Joan Cucchiara" <[e-mail]> wrote:




        Hello,

        Yes, I think the MIB is ready to be accepted as a working group
        document.

        As a comment (for a working group draft revision) would like to
        see an explanation of how to configure index values with a
        populated mplsTunnelTable.

        TOM: Cool. We will add that to the document in the next revision.

            --Tom



        Thanks,
          -Joan





                ----- Original Message -----

                From:  Adrian  Farrel <mailto:[e-mail]>

                To: 'venkatesan mahalingam' <mailto:[e-mail]>  ; [e-mail] ; 'mpls' <mailto:[e-mail]>

                Cc: [e-mail] ; [e-mail] ; [e-mail] ; [e-mail]

                Sent: Saturday, June 04, 2011 5:05  PM

                Subject: RE: poll on  draft-vkst-mpls-tp-te-mib-00.txt





                Thanks  Venkat,



                [Recalling  that I am speaking as an individual contributor and not as  AD]



                This  revision is much improved and I think the I-D would form a good basis for  further WG work.



                Adrian







                From: venkatesan mahalingam [mailto:[e-mail]]
                Sent: 04 June 2011 20:20
                To: Adrian Farrel; [e-mail];  mpls
                Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
                Subject:  Fwd: poll on draft-vkst-mpls-tp-te-mib-00.txt





                Dear Adrian and Joan,







                We have addressed the 3 major comments identified by you  during WG adoption poll. Apologies for the delayed response as we wanted to  address each item carefully and get consensus among authors of this  document.







                1. MPLS-TE-STD-MIB is extended by MPLS-TP-TE-STD-MIB mib  module



                   The 'extends' relationship is a sparse  augmentation so that the entry in the



                   mplsTpTunnelTable has the same index values.  Redefining of the index definitions is now removed and the table is  referenced



                   with the same indices as in  mplsTunnelTable.







                2. Separate mib module for textual conventions created for  MPLS-TP mib modules. This is part of the present  MIB,



                   which will be published separately,  later.







                3. Separate mib modules for MPLS-TP-TC-STD-MIB,  MPLS-TP-ID-STD-MIB, MPLS-TP-LSR-STD-MIB and



                   MPLS-TP-TE-STD-MIB have been created. These  are presently part of this MIB, so as overcome the mib compilation  issues.



                   These mibs will be published as separate  drafts, after the adoption.







                Apart from the above we have taken care of minor issues as  well. We think, the issues raised were addressed, and the document is ready to  be adopted as WG doc. Any changes, if needed, we will address in the  subsequent revisions. Kindly let us know if you have any  questions.







                New version can be accessed through this below  URL,



                http://tools.ietf.org/html/draft-vkst-mpls-tp-te-mib-01







                Thanks,



                Venkat.





                ---------- Forwarded message  ----------
                From: venkatesan mahalingam <[e-mail]>
                Date: Mon,  May 9, 2011 at 5:29 PM
                Subject: RE: poll on  draft-vkst-mpls-tp-te-mib-00.txt
                To: [e-mail], [e-mail], mpls <[e-mail]>
                Cc: [e-mail], [e-mail], [e-mail]




                Hi Adrian and all,



                Please find the responses inlined with the tag  <<TP-MIB-Authors>>







                Thanks,



                TP-MIB-Authors.



                ________________________________________



                From: Adrian Farrel [[e-mail]]



                Sent: Saturday, May 07, 2011 3:40 AM



                To: [e-mail];  [e-mail]



                Cc: [e-mail]; [e-mail]; [e-mail]



                Subject: RE: poll on  draft-vkst-mpls-tp-te-mib-00.txt








                >[speaking as an individual WG  participant]







                >I support the idea of constructing a MIB module for  MPLS-TP LSPs and for other



                >elements of MPLS-TP, but I have significant  reservations about adopting this



                >document in its current form. I recognise that once  adopted, the WG will be able



                >to enforce changes in content, but I am concerned that  this document does not



                >correctly reflect the relationship with other MIB  modules, and that taking this



                >as a starting point will encourage us to go down the  wrong path resulting in a



                >starting direction that will be hard to  change.







                >I would be happy to see the authors spend a little more  time on this and then



                >adopt it into the WG.







                >In overview my concerns are as  follows:







                > mplsGlobalId, mplsIcc and mplsNodeId are node  properties that will turn out



                > to



                > be equally applicable for PWs. They should appear in a  MIB module dedicated



                > to



                > the LSR not just to the MPLS-TP LSPs. Given that these  three objects and



                > mplsNodeConfigTable and mplsNodeIpMapTable are all  related to MPLS-TP



                > identifiers, why not have a separate module for them  all?











                <<TP-MIB-Authors>> We agree that mplsGlobalId,  mplsIcc and mplsNodeId can be kept in a common mib module.



                mplsNodeConfigTable is created specifically to map the  [Global-id_Node-id]



                and Icc-id into Local-Num. This Local-Num will be used as  the tunnel source/destination identifier.







                This idea has been followed to retain the MPLS tunnel table  for MPLS-TP TE extensions also.



                We think that mplsNodeConfigTable/mplsNodeIpMapTable is not  applicable for PWs.



                The reason is that we already have the 129 FEC PWs with  variable length of SAII & TAII.



                And the SAII & TAII already includes the Global-Id and  Node-Id (or ICC Id)



                Since the MPLS-TP PWs are always FEC129 Type2 based PWs,  the flexibility in SAII & TAII



                can be used to configure Global-id/Node-id or ICC  id.












                > A number of objects related to Global IDs and Node IDs  appear to be of the



                > wrong



                > max value compared to draft-ietf-mpls-tp-identifiers.  You could usefully



                > define



                > TCs for them and for the ICC ID.  What will zero  Global IDs and Node IDs



                > mean?











                <<TP-MIB-Authors>> Yes, the Max value of  Global-Id and Node-id are wrong. Max value should be max



                of 4 bytes value. We will correct them.







                Yes, we can keep the TCs for Global-id/Node-id and ICC-id  in a seperate mib



                module.



                1) A Global_ID of zero means that no Global_ID is  present.



                2) A Node_ID of zero is the default value that indicates  the Node_ID is



                invalid.












                > I see the value of the ICC entries in  mplsNodeConfigTable and the use of



                > mplsNodeIccMapTable to generate a unique index to use  in defining entries in



                > the



                > various pre-existing tables. (But see my comment on  the use of



                > mplsNodeConfigLocalNum in mplsTunnelExtEntry, below).  I do not see the value



                > of



                > the Global entries in mplsNodeConfigTable and the use  of mplsNodeIpMapEntry



                > since you say in the preamble to mplsTunnelExtEntry  that Source-Tunnel_Num



                > is



                > mapped with mplsTunnelIndex. Quite possibly there is  descriptive text



                > missing.







                <<TP-MIB-Authors>> mplsNodeConfigTable is  the configuration table that is used to configure Global-id/Node-id and/or  ICC-id with



                the local map number. i.e. This table is used to configure  the global-id/Node-id and/or ICC-id for the



                given local map number.







                The other two tables mplsNodeIpMapEntry and  mplsNodeIccMapTable are just READ-ONLY tables.



                These read only tables are meant for users who want to view  the reverse mapping of Global-id/Node-id



                or ICC-id to the LocalNum.








                > There seems to be some ambiguity about whether the  objects in this document



                > refer to MPLS-TP or to extensions to MPLS-TE. it would  be really nice to



                > sort



                > this out.







                <<TP-MIB-Authors>> This document is created to  address the requirements of TE extensions



                for MPLS-TP and this will also be applicable for MPLS TE  and hence the mib modules are



                named generically. Since we are augmenting the TE mib, we  named it as TE extension.



                If many others prefer to name this as TP extension, we can  change the names accordingly.












                > mplsTunnelExtEntry is defined as augmenting  mplsTunnelEntry. I'm guessing



                > you



                > actually want a sparse augmentation since in a "mixed"  environment you will



                > not



                > want to have all these objects present but unused. So  you need to change the



                > way



                > you define this.







                <<TP-MIB-Authors>> Yes, we actually meant  sparse augmentation. This mplsTunnelExtEntry



                will have entries only when required.



                For example, this table will have entries for the MPLS-TP  tunnels, but not for MPLS tunnels.



                Does it answer your question?



                Do you expect few more description to be added to this  table?



                Also, do you foresee any issue of augmentation? Is it  possible to explain the same?








                > In mplsTunnelExtTable you do not state what  DstTunnelNum is mapped with.



                > This is



                > key and could completely break your augmentation  unless you get it right!







                <<TP-MIB-Authors>> There are two ways to look  at this problem. One way is to force the DstTunnelNum as  key.



                Other way is NOT to force it as key. Let us take an example  to demonstrate this.



                Let us say that we have a forward LSP with SrcTunnel_100,  Instance_1, Source_R1, Destination_R5, DstTunnel_200.



                Option1: Force DstTunnelNum as key:



                If we mandate DstTunnelNum as key, then the following  combination is theoretically valid.



                LSP1: SrcTunnel_100, Instance_1, Source_R1, Destination_R5,  DstTunnel_200



                LSP2: SrcTunnel_100, Instance_1, Source_R1, Destination_R5,  DstTunnel_300. Even though the LSP2 is theoretically  valid,



                it is not correct to have same indices for the forward LSP.  i.e Treating the LSP2 as separate



                independent LSP is not looking correct. Hence, the Option1  is dropped.







                Option2: Do not force DstTunnelNum as  key:



                This is the option that we choose. i.e User can configure  DstTunnelNum as read-write column,



                but it is not part of indices to mplsTunnelTable. If we try  to include that as key,



                even the existing MPLS based mplsTunnelTable will have  problems in interpretation.



                Also, we do not see a real need to force that as index/key.  According to this option, the LSP1 is a valid combination.



                LSP1: SrcTunnel_100, Instance_1, Source_R1, Destination_R5,  DstTunnel_200



                If user wants to use a different reverse LSP, they can  modify the DstTunnel value as 300.



                But, it will still be called as LSP1.



                LSP1: SrcTunnel_100, Instance_1, Source_R1, Destination_R5,  DstTunnel_300 (modified).



                If required, we can discuss with mpls-tp-identifiers  authors to confirm whether this approach is fine.












                > For mplsTunnelExtEntry you have...



                >             Source  Global identifier/ICC and Destination



                >             Global  identifier/ICC are maintained in the



                >              mplsNodeConfigTable and mplsNodeConfigLocalNum is used to



                >             create an  entry in mplsTunnelTable.



                > This is possibly too vague to be actually  practical.







                <<TP-MIB-Authors>> We created a word document  to explain the various options that were considered



                before taking this option. We will share the same with  you.



                In principle, the idea is to reuse the mplsTunnelTable  without disturbing its existing meaning for MPLS based  tunnels.



                Even though we can think of alternate designs based on  separate new table for MPLS_TP tunnels,



                we thought that reusing the existing table is a better  option since MPLS_TP is just an extension of existing  MPLS.



                You can go through our document and provide your  comments.












                > How will mplsTunnelExtDestTnlIndex actually be  used?



                > - What value will it have for unidirecitonal  tunnels?



                >   (Or for bidriectional associated tunnels where  the reverse



                >    direction is not present on this  LSR)







                <<TP-MIB-Authors>> A zero value will be held by  this (mplsTunnelExtDestTnlIndex) object



                when the unidirectional tunnel is  desired.



                This object contains the source tunnel index value incase  of co-routed



                bidirectional tunnel and for associated  bidirectional



                tunnel this object contains the reverse direction tunnel  index and



                reverse lsp index object will be added in the next version  of this draft.












                > - Is this actually meant to be the object that gives  us the



                >    DstTunnelNum? If so, what has this to do  with the reverse



                >    direction?







                <<TP-MIB-Authors>> Yes, this helps to associate  the forward/reverse direction tunnels for



                associated bi-directional tunnel.



                For co-routed bidirectional case, SrcTunnelNum =  DstTunnelNum and



                SrcTunnelLspNum = DstTunnelLspNum,



                this is because we use same tunnel entry with two different  XC entries for



                both forward and reverse direction  LSPs.








                > It is completely unclear to me what  mplsTunnelExtTnlApp is for!







                <<TP-MIB-Authors>> This object provides the  information on whether the tunnel entry is



                MPLS tunnel or the MPLS-TP tunnel (tunnel application is  either MPLS



                or MPLS-TP).












                > It certainly makes a nonsense of  mplsTpTunnelsConfigured and



                > mplsTpTunnelsActive







                <<TP-MIB-Authors>> This is to keep the tunnel  count for MPLS-TP specific tunnels which are



                configured as mplsTp in mplsTunnelExtTnlApp object. If the  object is not going



                to be useful for users, this can be  removed.













                >Cheers,



                >Adrian











                > -----Original Message-----



                > From: [e-mail] [mailto:[e-mail]]



                > Sent: 03 May 2011 18:48



                > To: [e-mail]



                > Cc: Adrian Farrel; [e-mail]; [e-mail]; draft-vkst-mpls-tp-



                > [e-mail]



                > Subject: poll on  draft-vkst-mpls-tp-te-mib-00.txt



                >



                >



                > Working Group,



                >



                > this is to start a two week poll on  making



                >



                > draft-vkst-mpls-tp-te-mib-00.txt



                >



                > an mpls working group document.



                >



                > If you support the document becoming a working group  document



                > please respond to this poll with  "yes/support"



                >



                > If you do not support the document becoming a working  group



                > document please respond to this poll with "no/do not  support"



                > and at the same time give the technical reasons why  you are



                > not supporting the document.



                >



                > If you have technical comments or in any other way  want to



                > discuss the document, please send these comments to  the mpls



                > working group mailing list, but with another subject  than what



                > is on this mail.



                >



                > The poll ends 2011-05-18.



                >



                > /Loa