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

From: Venkatesan Mahalingam <[email-masked]>
Date: Sun, 2 Sep 2012 00:34:18 -0700

MIB Doctors,

Please review the new changes attached and let us know if you have any
more comments.

Thanks,
Venkat.
On Tue, Aug 21, 2012 at 12:10 PM, Sam Aldrin <[email-masked]> wrote:
> 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 <[email-masked]> 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 <[email-masked]> wrote:
>>
>>> ++ MPLS WG & MIB Drs.
>>>
>>> Thanks,
>>> Venkat.
>>>
>>> On Fri, Aug 17, 2012 at 1:36 PM, Joan Cucchiara
>>> <[email-masked]> 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"
>>>> <[email-masked]>
>>>> To: "Joan Cucchiara" <[email-masked]>
>>>> Cc: "Thomas Nadeau" <[email-masked]>; "Sam Aldrin"
>>>> <[email-masked]>; "Kannan KV Sampath" <[email-masked]>
>>>> 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
>>>>> <[email-masked]> 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" <[email-masked]>
>>>>>> 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
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mpls
>>
>

---

From: "Joan Cucchiara" <[email-masked]>
Date: Wed, 5 Sep 2012 12:22:00 -0400

Hello Venkat,

Thank you for adding the example to show what happens wrt these MIB Modules
when a MPLS TE TP Tunnel is signaled, however, I think the example is incomplete.

The example does not show how rows are created in the mplsTunnelExtNodeConfigTable
or mention that rows shoud be created in the mapping tables, although the following snippet
of the example in Section 9.3 indicates that rows are created in these tables:

"-- Local map number created in mplsTunnelExtNodeConfigTable for
   -- Ingress LSR-Id
     mplsTunnelIngressLSRId       = 1,

   -- Local map number created in mplsTunnelExtNodeConfigTable for
   -- Egress LSR-Id
     mplsTunnelEgressLSRId        = 2,"

Additionally, these are the same index values used in the previous example and there is no
discussion on why these values were chosen.    How are these values chosen?   What is the
algorithm or method for choosing these?   If the local management entity just picks the first available
indexes which are not already in the MplsTunnelTable, then that should be stated.    

Looking further in this example:

    "mplsTunnelSignallingProto    = none (1),"

Why is the signaling protocol marked as "none"?     

The MPLS RFCs which this draft references (e.g. RFC3811, RFC6370) use the term "operator" rather than "administrator".
Please use the term "operator" to be consistent with the RFCs.

Also, we have already discussed using the term "local management entity" and not "implementor".
Local Management Entity is appropos for a MIB.    Please replace this in the draft, particularly in the
mplsExtTunnelTable DESCRIPTIONS.    

Thanks,
  -Joan

  ----- Original Message ----- 
  From: Venkatesan Mahalingam 
  To: Joan Cucchiara ; MIB Doctors (E-mail) 
  Cc: Sam Aldrin ; Thomas Nadeau ; Kannan Sampath 
  Sent: Sunday, September 02, 2012 3:34 AM
  Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib-04.txt review request

  MIB Doctors,

  Thanks,
  Venkat.

---

From: Venkatesan Mahalingam <[email-masked]>
Date: Wed, 5 Sep 2012 09:43:56 -0700

Thanks Joan, We will address your comments soon.

Do you still see an issue with the mplsTunnelExtNodeConfigLocalId MIB
object's description?

mplsTunnelExtIngressLSRLocalIdValid and
mplsTunnelExtEgressLSRLocalIdValid MIB objects are added newly to
denote whether the LSRId
contains the local value (need to refer NodeConfigTable to get the
complete LSR-id) or mplsTunnelIngress/EgressLSRId is complete by
itself, do you still see a legacy MPLS TE tunnel operability issue
because of the new MPLS-TP specific MIB object changes?

Thanks,
Venkat.

On Wed, Sep 5, 2012 at 9:22 AM, Joan Cucchiara
<[email-masked]> wrote:
> The MPLS RFCs which this draft references (e.g. RFC3811, RFC6370) use the
> term "operator" rather than "administrator".
>> 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:
>> 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.
>>>
>>>
>> 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.
>>>
>> 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.
>>>
>> 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.
>>>
>>>

---

From: "Joan Cucchiara" <[email-masked]>
Date: Thu, 6 Sep 2012 09:31:23 -0400

Venkat,

Since the example is incomplete and the DESCRIPTION clauses related to the
MplsExtendedTunnelId TC will change, I don't see the point of reviewing and 
giving a
thumbs up/down.   I can't in good conscience ask other MIB Drs
for their guidance at this point because  I feel like that would be a waste 
of their time.

Additionally, not all of the comments in the original review during LC were
taken into account -- one is to change names to contain "TP" since this MIB
deals exclusively with additions due to Transport Protocol.   That was 
agreed to
by the authors and has not been done.  It is also in the MIB review 
guidelines as I have
pointed out in a prior email.    I haven't asked for this again, because I 
just
want the example and wording to be correct, but my understanding of the IETF 
process
is that LC comments should be discussed, agreed to, and incorporated.   They 
have
been discussed and the authors agree to incorporate this change, but it has 
not
been done.

Also, there are extremely few REFERENCE clauses (about 4 or 5) and
those that exist reference an entire Document where I would expect to see
a section or subsection referenced.     That doesn't make things easier
for a reviewer (or future readers) of this doc.

Additionally, there were comments by another WG member  (repeated here for 
convience)
that have not been updated but the authors agreed to do so:

"Subject: [mpls] Typos in draft-ietf-mpls-tp-te-mib-04
Date: Tue, 17 Jul 2012 10:47:32 +0000
From: Muly Ilan <[email-masked]>
To: [email-masked] <[email-masked]>

Hi,

1.Section 9.2.6 should be renamed to "Reverse direction mplsTunnelEntry"
instead of "Forward direction mplsTunnelEntry".

2.In section 9.2.10 change "mplsXCExtTunnelPointer         =
mplsTunnelName.1.1.1.2" to "mplsXCExtTunnelPointer         =
mplsTunnelName.2.1.2.1".

Muly"

I think Muly is being kind, these aren't typos in my opinion, they are fixes 
to mistakes.

These are just a few items off the top of my head and not a complete list.

So, in truth, I haven't focused on all these other updates that need to 
happen because I
have been waiting for the wording and examples related to the 
MplsExtendedTunnelId
to become stable.

I would like to ask that one of you becomes editor for this document, 
because all this back-n-forth
is counterproductive.   Many of the requests by myself and others are just 
falling to the wayside.
I would expect that an editor is willing to keep a list of all the updates 
that have been agreed to and
make sure that these are incorporated into the document.

Thanks,
   -Joan

----- Original Message ----- 
From: "Venkatesan Mahalingam" <[email-masked]>
To: "Joan Cucchiara" <[email-masked]>
Cc: "MIB Doctors (E-mail)" <[email-masked]>; "Sam Aldrin" 
<[email-masked]>; "Thomas Nadeau" <[email-masked]>; "Kannan 
Sampath" <[email-masked]>
Sent: Wednesday, September 05, 2012 12:43 PM
Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib-04.txt review request

>> Additionally, these are the same index values used in the previous 
>> example
>> and there is no
>> discussion on why these values were chosen.    How are these values 
>> chosen?
>> What is the
>> Also, we have already discussed using the term "local management entity" 
>> and
>> not "implementor".
>> Local Management Entity is appropos for a MIB.    Please replace this in 
>> the
>> draft, particularly in the
>>>> So why was the above (extremely helpful) information not included as 
>>>> part
>>>> of the
>>>> DESCRIPTION clause?
>>>> No where in the DESCRIPTION does it say this is a "hint" to the 
>>>> operator
>>>> (you say
>>>> 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.
>>>>> The example provided could give guidance on what value to use, but 
>>>>> will
>>>>> not
>>>>> MANDATE the usage.
>>>>>
>>> Will send the new text for review, soon. If you have other issues, 
>>> please
>>> do let us know.
>>>
>>> -sam
>>>>
>>>> Thanks,
>>>> -Joan
>>>>
>>>>>> Please include the MIB Dr's on your email because this is a MIB 
>>>>>> concern
>>>>>> and
>>>>>> one which I've had since
>>>>>> 2) update RFC3811 to accurately reflect MplsExtendedTunnelId and 
>>>>>> other
>>>>>> RFCs
>>>>>> which utilize this TC.
>>>>>> 3) ??
>>>>>>
>>>>>> Thanks,
>>>>>> -Joan
>>>>>>
>>>>>>
>>>>>>>> We are away this week returning on 7/23.   Sorry, I can't review 
>>>>>>>> the
>>>>>>>> doc
>>>>>>>> This version addresses all your comments. Highlighting couple of 
>>>>>>>> them
>>>>>>>> to
>>>>>>>> value of non-IP address, we are using it. This will make the 
>>>>>>>> indices
>>>>>>>> for
>>>>>>>> the
>>>>>>>> same as TunnelTable.
>>>>>>>> Appreciate if you can get back by Monday noon time PST. I know it 
>>>>>>>> is
>>>>>>>> a
>>>>>>>> very

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 6 Sep 2012 11:07:07 -0700

Hi Joan,

With too many threads and many mails back and forth, created a lot of confusion. Apologies for that. Going forward here is what we plan to do.

- I will be the POC and will own the pen and responsible for communicating with you and MIB Dr's.
- Will keep track of all the issues and points raised by you and all others and ensure that they are closed.
- Only after all the issues are addressed, we consider them as closed and publish a new version.

Having said that, feel free to communicate to me if you have any other issues with MIB or outside of it. Will definitely be more proactive in communicating with you and ensure that they are addressed.

In regards to this version, all Venkat was doing is to resolve the issue with Ingress and Egress LSR ID's. As it is very important issue, wanted to address that first. No way this version addressed all of the issues raised. Granted that it is not efficient way to use ones time. Anyway, will put forth a version for review, shortly, with all the comments addressed. Hope this is acceptable to you and others. If not, let me know. Open to suggestions and comments.

thanks for your time.

Cheers
-sam

On Sep 6, 2012, at 6:31 AM, "Joan Cucchiara" <[email-masked]> wrote:

> MplsExtendedTunnelId TC will change, I don't see the point of reviewing and giving a
> for their guidance at this point because  I feel like that would be a waste of their time.
> 
> deals exclusively with additions due to Transport Protocol.   That was agreed to
> by the authors and has not been done.  It is also in the MIB review guidelines as I have
> pointed out in a prior email.    I haven't asked for this again, because I just
> want the example and wording to be correct, but my understanding of the IETF process
> is that LC comments should be discussed, agreed to, and incorporated.   They have
> been discussed and the authors agree to incorporate this change, but it has not
> been done.
> 
> Additionally, there were comments by another WG member  (repeated here for convience)
> I think Muly is being kind, these aren't typos in my opinion, they are fixes to mistakes.
> 
> So, in truth, I haven't focused on all these other updates that need to happen because I
> have been waiting for the wording and examples related to the MplsExtendedTunnelId
> to become stable.
> 
> I would like to ask that one of you becomes editor for this document, because all this back-n-forth
> is counterproductive.   Many of the requests by myself and others are just falling to the wayside.
> I would expect that an editor is willing to keep a list of all the updates that have been agreed to and
> ----- Original Message ----- From: "Venkatesan Mahalingam" <[email-masked]>
> Cc: "MIB Doctors (E-mail)" <[email-masked]>; "Sam Aldrin" <[email-masked]>; "Thomas Nadeau" <[email-masked]>; "Kannan Sampath" <[email-masked]>