Re: [mpls] draft-ietf-mpls-tp-te-mib-04.txt review request

[Sam Aldrin <[e-mail]>]

Hi Joan,

Thanks for the email. Sorry for the delayed email. Was on PTO.
Please find my comments inline.

thanks
-sam
On Aug 19, 2012, at 6:40 AM, Joan Cucchiara <[e-mail]> wrote:

>> Hi Joan,
>> 
>> The issue boils down to the range value specified in the DESCRIPTION.
>> If that is removed, does that resolve the concern you raised?
> 
> Sam,
> 
> I think that depends on how the new DESCRIPTION clause is worded.
> This DESCRIPTION was brought up as a MAJOR concern and
> the authors agreed to reword it for 04, but that was not done.
> 
> Please see inline below.
> 
>> Do not think we are restricting not to use '0' in anyway or redefining the
>> semantics.
>> 
>> As the value is local and the intention is to help implementor of the MIB to
>> choose right value, without conflicting with TE tunnel index, we added that
>> range. If implementor chooses to use different value altogether, it is
>> perfectly OK as long as it is in the range of mplsExtendedTunnelId
>> definition.
> 
> So why was the above (extremely helpful) information not included as part of the
> DESCRIPTION clause?
Yes, it should have been. We will send a new text for the description for review, which will reflect what we were discussing. Hopefully, that will remove the confusion.
> 
> The object is:
> 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 1 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, administrator 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 administrator to assign
>           a unique identifier to map Global_Node_ID and/or ICC."
>        ::= { mplsTunnelExtNodeConfigEntry 1 }
> 
> 
> No where in the DESCRIPTION does it say this is a "hint" to the operator (you say
> implementor, but think you mean the operator, i.e. the person that configures this MIB table.)
Agree. 
When I say implementor, I was implying in the case of signaled, where the localID to be derived. Operator is also right term when the tunnel is configured statically. New description will provide right details in the case of static and control plane signaled TP tunnels.
> 
> 
>> W.r.t legacy implementation, it is unto the implementor to assign the right
>> index value to TP tunnel, if it conflicts with TE tunnel index.
> 
> 
> Yes, but the draft says in Section 9. "Do note that a MPLS-TP tunnel could be setup statically as well as
> signaled via control plane."  so if the tunnel is signaled, then what happens?   Are there entries
> created in these tables by the local management subsystem (e.g. agent) when the MPLS TP tunnel is signaled
> successfully  OR are entries entirely dependent on an operator for configuration?
When signaled, the local agent will create those entries. It needs to derive the localID, which is unique only on the local system as it is locally significant. In order not to conflict with legacy TE implementation, we 'suggest' to use the value which is below valid IP address value. 
> 
> As far as I can tell, the MIB does not support  signaled TP tunnels, is this correct?
> If so, that needs to be clearly stated, particularly in the Abstract.
That is not correct. It does support. We never restricted the MIB to static TP tunnels only. We will add explicit statement in the abstract to remove the confusion.
> 
> If I am wrong and it does support signaled TP Tunnels then, how does that work with mapping tables?
> While there is an example for statically configured tunnels, I don't see one for Signaled TP Tunnels.
As I mentioned above, the local ID is derived as in the given example. If needed, we can add more text or details in the example section, w.r.t signaled vs static.
> 
> 
>> The example provided could give guidance on what value to use, but will not
>> MANDATE the usage.
>> 
>> In regards to implementing a new table, we have deliberated extensively
>> among authors and also with implementors. Adding new MIB or table is not
>> really efficient. Infact, there are already implementations which were able
>> to support the legacy model as well as new TP tunnels. Unless there is a
>> compelling reason that MPLS TP tunnel table should have its own table, which
>> essentially duplicated all of the objects, I am not for that model. If
>> others in WG feels the need, they can speak up.
> 
> 
> I'd like to see the new DESCRIPTION clause and understand about MPLS TP signaled
> tunnels wrt to this draft, prior to delving into the above (and other issues).
Will send the new text for review, soon. If you have other issues, please do let us know.

-sam
> 
> Thanks,
> -Joan
> 
> On Aug 17, 2012, at 1:51 PM, Venkatesan Mahalingam <[e-mail]> wrote:
> 
>> ++ MPLS WG & MIB Drs.
>> 
>> Thanks,
>> Venkat.
>> 
>> On Fri, Aug 17, 2012 at 1:36 PM, Joan Cucchiara
>> <[e-mail]> wrote:
>>> Venkat,
>>> 
>>> The SMIv2 specifies that once a TC is defined, then the definition cannot
>>> change in the way being
>>> proposed by the draft-ietf-mpls-tp-te-mib-04.
>>> 
>>> From RFC2579:
>>> 3.3.  Mapping of the DESCRIPTION clause
>>> The DESCRIPTION clause, which must be present, contains a textual
>>> definition of the textual convention, which provides all semantic
>>> definitions necessary for implementation, and should embody any
>>> information which would otherwise be communicated in any ASN.1
>>> commentary annotations associated with the object.
>>> 
>>> 
>>> My concern is that MPLS-TC-STD-MIB defines MplsExtendedTunnelId and this
>>> draft is changing that original definition.
>>> If RFC3811 does not contain "all semantic definitions necessary for
>>> implementation" then the problem is to update RFC3811
>>> and maybe other associated RFCs as needed, not to propose additional
>>> semantics in draft-ietf-mpls-tp-te-mib.
>>> 
>>> The draft is proposing to bifurcate the values and also not use zero for the
>>> MplsExtendedTunnelId, that is not the original
>>> definition of MplsExtendedTunnelId, so why is this draft using
>>> MplsExtendedTunnelId?
>>> 
>>> Please include the MIB Dr's on your email because this is a MIB concern and
>>> one which I've had since
>>> before this draft was adopted as a WG document.
>>> 
>>> The options are (as I see them):
>>> 1) create a specific MPLS TP table for TP Tunnels (which was originally
>>> proposed by Adrian Farrel)
>>> 2) update RFC3811 to accurately reflect MplsExtendedTunnelId and other RFCs
>>> which utilize this TC.
>>> 3) ??
>>> 
>>> Thanks,
>>> -Joan
>>> 
>>> 
>>> ----- Original Message ----- From: "Venkatesan Mahalingam"
>>> <[e-mail]>
>>> To: "Joan Cucchiara" <[e-mail]>
>>> Cc: "Thomas Nadeau" <[e-mail]>; "Sam Aldrin"
>>> <[e-mail]>; "Kannan KV Sampath" <[e-mail]>
>>> Sent: Friday, August 17, 2012 2:39 PM
>>> 
>>> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request
>>> 
>>> 
>>>> Joan,
>>>> 
>>>> Thanks for your response. Appreciate your time for reviewing this
>>>> draft. Please find below my response tagged [VM].
>>>> 
>>>> However, I looked over the doc and wanted to let you know that I still
>>>> have
>>>>> 
>>>>> the same issue wrt to both SYNTAX and semantic
>>>>> redefinition as before.   You cannot narrow the range of values in a
>>>>> DESCRIPTION clause which I see happens in mplsTunnelExtNodeConfigLocalId
>>>>> and maybe  in MplsNodeId TC as it says zero must not be used, but then
>>>>> you
>>>>> have it as part of allowable values in the SYNTAX.
>>>> 
>>>> [VM] If MplsExtendedTunnelId allows zero as the valid value, I don't
>>>> see any issue to allow zero as the valid value for MplsNodeId.
>>>> 
>>>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any
>>>>> Unsigned32 and says "may represent an IPv4 address".    If (for whatever
>>>>> reason) an
>>>>> operator has configured something in the 1..16777216 (i.e. Local Id)
>>>>> range,
>>>>> for a regular TE Tunnel, that is perfectly legal, right?
>>>> 
>>>> [VM] I don't see any implementation which allows non-IP TE tunnel
>>>> source/destination in the range 1..16777216 in MPLS domain,
>>>> if you are not still convinced, we can poll in MPLS WG list to get the
>>>> operators' opinion on this.
>>>> 
>>>>> If the answer is Yes, then how would you add TP Tunnels using your draft
>>>>> if
>>>>> an operator has a regular MPLS TE Tunnel configured
>>>>> in the range 1..16777216 without having to ensure that any and all legacy
>>>>> equipment be queried first?
>>>> 
>>>> [VM] It is expected to configure MPLS TE tunnels in IP address range
>>>> and MPLS-TP tunnel in NON-IP range, if the implementors have mixed
>>>> mode of configuration, then it is expected to clarify in the document
>>>> that how to use MPLS-TE & MPLS-TP tunnel configurations.
>>>> What you are saying is correct only if the legacy equipments use the
>>>> NON-IP range for MPLS TE tunnels, so, as I stated above, let's close
>>>> this with the MPLS WG list.
>>>> 
>>>> HTH
>>>> 
>>>> Thanks,
>>>> Venkat.
>>>> 
>>>> On Fri, Aug 17, 2012 at 10:21 AM, Joan Cucchiara
>>>> <[e-mail]> wrote:
>>>>> 
>>>>> Tom and all,
>>>>> 
>>>>> Unfortunately, my linux box is giving me grief this week (and I don't
>>>>> have
>>>>> access to my MIB tools).   I'm getting some assistance
>>>>> with it but won't be resolved until (hopefully) during the weekend.
>>>>> 
>>>>> However, I looked over the doc and wanted to let you know that I still
>>>>> have
>>>>> the same issue wrt to both SYNTAX and semantic
>>>>> redefinition as before.   You cannot narrow the range of values in a
>>>>> DESCRIPTION clause which I see happens in mplsTunnelExtNodeConfigLocalId
>>>>> and maybe  in MplsNodeId TC as it says zero must not be used, but then
>>>>> you
>>>>> have it as part of allowable values in the SYNTAX.
>>>>> 
>>>>> Whatever is specified in the DESCRIPTION clause for values, should be
>>>>> reflected by the SYNTAX, right?
>>>>> 
>>>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any
>>>>> Unsigned32 and says "may represent an IPv4 address".    If (for whatever
>>>>> reason) an
>>>>> operator has configured something in the 1..16777216 (i.e. Local Id)
>>>>> range,
>>>>> for a regular TE Tunnel, that is perfectly legal, right?
>>>>> 
>>>>> 
>>>>> 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)
>>>>> 
>>>>> If the answer is Yes, then how would you add TP Tunnels using your draft
>>>>> if
>>>>> an operator has a regular MPLS TE Tunnel configured
>>>>> in the range 1..16777216 without having to ensure that any and all legacy
>>>>> equipment be queried first?
>>>>> 
>>>>> Thanks,
>>>>> -Joan
>>>>> 
>>>>> 
>>>>> 
>>>>> ----- Original Message -----
>>>>> From: Thomas Nadeau
>>>>> To: Joan Cucchiara
>>>>> Cc: Sam Aldrin ; Venkatesan Mahalingam ; Kannan KV Sampath
>>>>> Sent: Thursday, August 09, 2012 8:58 AM
>>>>> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request
>>>>> 
>>>>> hi Joan
>>>>> 
>>>>> hope you had a great vacation! ;)
>>>>> 
>>>>> can you please follow up on the note below when you have a chance?
>>>>> 
>>>>> Tom
>>>>> 
>>>>> 
>>>>> 
>>>>> On Jul 16, 2012, at 9:13 AM, "Joan Cucchiara" <[e-mail]>
>>>>> wrote:
>>>>> 
>>>>> Sam,
>>>>> 
>>>>> We are away this week returning on 7/23.   Sorry, I can't review the doc
>>>>> until after 7/23 and it will
>>>>> take a few days after that as I'll just be returning from vacation.
>>>>> 
>>>>> I glanced at it and see that there are read-write objects in a row (which
>>>>> is
>>>>> read-create) so that's
>>>>> an error which I mentioned before.
>>>>> 
>>>>> Have you compiled this with smilint?
>>>>> 
>>>>> Thanks,
>>>>> -Joan
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> ----- Original Message -----
>>>>> From: Sam Aldrin
>>>>> To: Joan Cucchiara
>>>>> Cc: Venkatesan Mahalingam ; Thomas Nadeau ; Kannan KV Sampath
>>>>> Sent: Friday, July 13, 2012 9:11 PM
>>>>> Subject: Fwd: draft-ietf-mpls-tp-te-mib-04.txt review request
>>>>> 
>>>>> Hi Joan,
>>>>> 
>>>>> Please find the updated MIB document. Apologize for the delay. We plan to
>>>>> publish the doc on Monday as it is the deadline before IETF. Diff file is
>>>>> attached as well.
>>>>> 
>>>>> This version addresses all your comments. Highlighting couple of them to
>>>>> make sure you are OK with them
>>>>> 
>>>>> 1. W.r.t mplsLocalID as index type, we have removed that using
>>>>> MplsExtendedTunnelId itself. As the value range for this object could
>>>>> have
>>>>> value of non-IP address, we are using it. This will make the indices for
>>>>> the
>>>>> same as TunnelTable.
>>>>> In the definition of IngressLSRId and and EgressLSRId, for TP entries, we
>>>>> added description to use value of non-IP address, which is local ID.
>>>>> 
>>>>> I do hope this satisfies the need and not necessitate for a new table
>>>>> altogether for TP.
>>>>> 
>>>>> 2. In regards to adding references to TC conventions. We believe, those
>>>>> were
>>>>> added in the reference section. IF we have missed any TC references,
>>>>> could
>>>>> you kindly let us know.
>>>>> 
>>>>> Appreciate if you can get back by Monday noon time PST. I know it is a
>>>>> very
>>>>> short time, but appreciate if you could do that.
>>>>> 
>>>>> thanks
>>>>> -sam
>>>>> 
>>>>> ________________________________
>>>>> 
>>>>> 
>>> 
>> _______________________________________________
>> mpls mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
>