Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance on draft-ietf-mpls-te-tp-mib-05.txt

From: Thomas Nadeau <[email-masked]>
Date: Mon, 3 Dec 2012 15:20:36 +0000

Recusing myself as a co-author of the document in question, I'd like to
just add a few points to the thread below to consider.

	1) While the corner case you make Joan is very real, it is also very
unlikely. The reason is that in all of the operational networks I've seen
where TE is deployed (and especially MPLS-TP/TE), there is a single
provisioning system that governs how, when and where tunnels are placed.
This would obviate the overlap case you pointed out.

	2) So as to not discount the case you point out, would it help to include
some sort of TunnelType field indicating explicitly that it is TP? I am
thinking of an enum like we have in RFC3813 mplsTunnelRole. This could
even be a boolean called mplsTpTunnelIsTP or something.

	--Tom

On 11/21/12 10:58 AM, "Joan Cucchiara" <[email-masked]> wrote:

>
>MIB Doctors,
>
>I would like your guidance.
>
>This draft proposes to add support of  Transport Profile (TP)
>for MPLS-TC-STD-MIB [RFC3811], MPLS-LSR-STD-MIB [RFC3813]
>and MPLS-TE-STD-MIB [RFC3812] c. 2004.
>
>Essentially, the mplsTunnelTable from the MPLS-TE-STD-MIB [RFC3812]
>could have entries created statically (i.e. manually by an operator) or
>dynamically.  MPLS-TE Tunnels are uni-directional while MPLS-TE Tunnels
>with Transport Profile are bi-direction (modelled as 2 uni-directional
>tunnels which are related in the proposed new doc.)
>
>I think the following 2 DESCRIPTIONs clauses are NOT the same
>semantically:
>
>Original MplsExtendedTunnelId [RFC3811]:
>
>       MplsExtendedTunnelId ::= TEXTUAL-CONVENTION
>          STATUS        current
>          DESCRIPTION
>             "A unique identifier for an MPLS Tunnel.  This may
>              represent an IPv4 address of the ingress or egress
>              LSR for the tunnel.  This value is derived from the
>              Extended Tunnel Id in RSVP or the Ingress Router ID
>              for CR-LDP."
>          REFERENCE
>             "RSVP-TE: Extensions to RSVP for LSP Tunnels,
>              [RFC3209].
>
>              Constraint-Based LSP Setup using LDP, [RFC3212]."
>          SYNTAX  Unsigned32(0..4294967295)
>
>Here is the index's DESCRIPTION which uses the above TC.
>To me, while syntactically equivalent are not
>semantically equivalent, so this is
>where I could use your guidance, please?
>
>
>      mplsTunnelExtNodeConfigLocalId  OBJECT-TYPE
>         SYNTAX        MplsExtendedTunnelId
>         MAX-ACCESS    not-accessible
>         STATUS        current
>         DESCRIPTION
>           "This object is used in accommodating the bigger
>            size Global_Node_ID and/or ICC with lower size LSR
>            identifier in order to index the mplsTunnelTable.
>
>            The Local Identifier is configured between 0 and 16777215,
>            as valid IP address range starts from 16777216(01.00.00.00).
>            This range is chosen to identify the mplsTunnelTable's
>            Ingress/Egress LSR-id is IP address or Local identifier,
>            if the configured range is not IP address, operator is
>            expected to retrieve the complete information
>            (Global_Node_ID or ICC) from mplsTunnelExtNodeConfigTable.
>
>            This way, existing mplsTunnelTable is reused for
>            bidirectional tunnel extensions for MPLS based transport
>            networks.
>
>            This Local Identifier allows the operator to assign
>            a unique identifier to map Global_Node_ID and/or ICC.
>            As this Local Identifier is unique within the node and
>            the same syntax of this object can be used for MPLS TE
>            tunnel also, it is up to the operator/local management entity
>to
>            choose the non-conflicting value for indexing the MPLS and
>            MPLS-TP tunnel entries."
>         ::= { mplsTunnelExtNodeConfigEntry 1 }
>
>
>The above "guideline" range of "0" to "16777215" is supposed to be a
>clue to operator  that this is an MPLS-TE Tunnel WITH Transport Profile,
>HOWEVER, there is nothing in the original MIB that disallows operators
>from
>manually configuring within this range.
>
>One scenario (even if unlikely):
>An MPLS TP with Transport Profile is configured dynamically,
>which conflicts with an older legacy NMS which is statically configuring
>MPLS TE Tunnel, and they both have chosen one of the same indexes
>(remember 
>that there are
>2 MplsExtendedTunnelId values for each tunnel.)   So again, while
>unlikely, 
>seems that there is
>potential conflict with legacy equipment.
>
>I would like other MIB Doctor guidance:
>
>Do you think (as I do) that the DESCRIPTION for
>mplsTunnelExtNodeConfigLocalId (above) semantically redefines
>the original MplsExtendedTunnelId TC?
>
>Thank you,
>  Joan
>
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 3 Dec 2012 10:01:33 -0800

Hi -

> From: "Thomas Nadeau" <[email-masked]>
> To: "Joan Cucchiara" <[email-masked]>; "Sam Aldrin" <[email-masked]>
> Cc: "Venkatesan Mahalingam" <[email-masked]>; "MIB Doctors (E-mail)" <[email-masked]>; "Kannan Sampath"
<[email-masked]>; "venkatesan mahalingam" <[email-masked]>
> Sent: Monday, December 03, 2012 7:20 AM
> Subject: Re: [MIB-DOCTORS] Request for MIB Doctor guidance on draft-ietf-mpls-te-tp-mib-05.txt
...
> even be a boolean called mplsTpTunnelIsTP or something.

As I understand it, the concern is that a management application might
attempt to use data of type MplsExtendedTunnelId as though it were an
address.  Adding other objects won't of itself fix that problem.

The best way I can see to mitigate the issue would be to add clarifying
text to RFC 3811 in the description of MplsExtendedTunnelId, and
possibly to add reminders of that clarification everywhere that textual
convention is used.  The next best thing might be to include warnings
against misuse in any new work using that textual convention.

Not having a stake in the controversy, and not being immersed in any
of these specifications, I'll just say that to me it seems that adding such
a clarification should go onto the editors' "to do" list in case RFC 3811
is ever updated.  However, as practical matter the severity of the issue
does not seem sufficient of itself to press the case for re-opening that
specification.  If folks were to decide that this should be documented
as an erratum, it would probably end up in the "hold for document
update" bin.

Randy

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 3 Dec 2012 18:04:21 +0000

On 12/3/12 1:01 PM, "Randy Presuhn" <[email-masked]> wrote:

>> Cc: "Venkatesan Mahalingam" <[email-masked]>; "MIB
>>Doctors (E-mail)" <[email-masked]>; "Kannan Sampath"

	Could add this as an errata with reference to the new document?

	--Tom

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 3 Dec 2012 10:23:13 -0800

Hi -

...
> Sent: Monday, December 03, 2012 10:04 AM
...
> Could add this as an errata with reference to the new document?

To me that sounds overly complicated.  The clarification to be added to
3811 would effectively be "don't count on this being an address, or
of even being a unique identifier outside the scope of the usage of this
textual convention within a particular context in a particular system."

Honestly, to me that warning is already carried by the weasel words
in the existing description, and that warning is only undermined by
the ambiguity about the scope of what being a unique identifier
entails where this TC is employed.

Randy