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

From: venkatesan mahalingam <[email-masked]>
Date: Thu, 5 May 2011 15:21:56 -0400

Yes/Support.

Regards,
Venkat.
________________________________________
From: Scott Mansfield [[email-masked]]
Sent: Wednesday, May 04, 2011 1:49 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] poll on draft-vkst-mpls-tp-te-mib-00.txt

Yes/support

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Tuesday, May 03, 2011 1:48 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [mpls] 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
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: venkatesan mahalingam <[email-masked]>
Date: Mon, 9 May 2011 17:29:48 -0400

Hi Adrian and all,
Please find the responses inlined with the tag <<TP-MIB-Authors>>

Thanks,
TP-MIB-Authors.
________________________________________
From: Adrian Farrel [[email-masked]]
Sent: Saturday, May 07, 2011 3:40 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
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

> From: [email-masked] [mailto:[email-masked]]
> Sent: 03 May 2011 18:48
> To: [email-masked]
> Cc: Adrian Farrel; [email-masked]; [email-masked];
draft-vkst-mpls-tp-
> [email-masked]
> Subject: poll on draft-vkst-mpls-tp-te-mib-00.txt
>
>
> Working Group,
>
> working group mailing list, but with another subject than what
> is on this mail.
>