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

From: [email-masked]
Date: Tue, 3 May 2011 19:47:46 +0200

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

---

From: Scott Mansfield <[email-masked]>
Date: Tue, 3 May 2011 16:19:25 -0400

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,
> 
> working group mailing list, but with another subject than 
> what is on this mail.
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Agrahara Kiran Koushik <[email-masked]>
Date: Thu, 5 May 2011 21:54:37 -0500

Support.

- Kiran Koushik.

> "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

---

From: Mach Chen <[email-masked]>
Date: Fri, 06 May 2011 03:14:12 +0000

Yes/support.

Mach

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, May 04, 2011 1:48 AM
> To: [email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 6 May 2011 23:10:23 +0100

[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?  

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?

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.

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.

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. 

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!

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.

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)
- Is this actually meant to be the object that gives us the 
   DstTunnelNum? If so, what has this to do with the reverse
   direction?

It is completely unclear to me what mplsTunnelExtTnlApp is for!
It certainly makes a nonsense of mplsTpTunnelsConfigured and mplsTpTunnelsActive

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,
>

---

From: "Joan Cucchiara" <[email-masked]>
Date: Sun, 8 May 2011 17:30:57 -0400

Hi,

While there seems to be a benefit to keeping all the "mpls" tunnels in one 
table
(i.e. the mplsTunnelTable in RFC3812).   I have a concern about
what seems to be a redefinition of the indexes for the mplsTunnelTable.

This draft contains a table:  mplsTunnelExtTable which
AUGMENTS the mplsTunnelTable in RFC3812.

The indexes are:
        INDEX {
              mplsTunnelIndex,
               mplsTunnelInstance,
               mplsTunnelIngressLSRId,
               mplsTunnelEgressLSRId
            }

The above indexes seem to be redefined in this draft (quoting from the
DESCRIPTION clause):

         "As per MPLS-TP Identifiers draft,  LSP_ID is

            Src-Global_Node_ID::Src-Tunnel_Num::Dst-Global_Node_ID::
            Dst-Tunnel_Num::LSP_Num for IP operator and

            Src-ICC::Src-Tunnel_Num::Dst-ICC::Dst-Tunnel_Num::LSP_Num
            for ICC operator,

            mplsTunnelTable is reused for forming the LSP_ID as follows,

            Source Tunnel_Num is mapped with mplsTunnelIndex,
            Source node identifier is mapped with
            mplsTunnelIngressLSRId, Destination node identifier is
            mapped with mplsTunnelEgressLSRId LSP_Num is mapped with
            mplsTunnelInstance.

            Source Global identifier/ICC and Destination
            Global identifier/ICC are maintained in the
            mplsNodeConfigTable and mplsNodeConfigLocalNum is used to
            create an entry in mplsTunnelTable."

Additionally,  one now needs to first configure an entry in the
mplsNodeConfigTable in this draft, then
one can create an entry in the mplsTunnelTable (RFC3812).

Adrian Farrel suggested that the mplsTunnelExtTable in this draft was 
probably meant to have
sparse-augments relationship to the mplsTunnelTable.    While I would agree 
that
this is probably the case, even with a
sparse-augments relationship, would the indexes redefined for TP be
acceptable?   I think not, although (as mentioned at the beginning), I
do see an advantage for having all mpls-based Tunnels in one table.

Would definitely like to see this discussed prior to accepting this draft 
was
a WG group document.

Thank you,
  -Joan

---

From: [email-masked]
Date: Tue, 24 May 2011 04:15:18 +0200

Working Group,

This poll has ended, we have had comments of such nature that
the authors agreed to re-publish an new version of the document
as an individual draft.

The decision whether the document will be accepted as a working
group document will be taken based on the new version of the
document.

/Loa
 MPLS wg co-chair