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

[Eric Gray <[e-mail]>]

Forwarding in plain text...

________________________________

From: Adrian Farrel [mailto:[e-mail]] 
Sent: Saturday, June 04, 2011 5:05 PM
To: 'venkatesan mahalingam'; [e-mail]; 'mpls'
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
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