Subject: Re: [mpls] RFC3815

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 8 Sep 2008 19:48:42 +0530

Hi,

I was just told that writing a bis-RFC it is the etiquette to retain
the older authors intact. I will do that from the next revision, after
asking their permission - sorry about the faux pas.

I have however got the authors as well as all older contributors in
the contributors list currently. As well as all older acknowledgments
as is.

Thanks,
Vishwas

On Mon, Sep 8, 2008 at 7:27 PM, Vishwas Manral <[email-masked]> wrote:
> Hi Adrian,
>
> Thanks a lot for the guidance. Based on your comments and talking to
> folks, I have decided to update the MPLS TC document. This will help
> any new MIB's to use the right TC. Of course I have obsoleted the
> earlier TC.
>
> In my view the changes can be incremental too. We can leave the STATUS
> of the older TC to current but specify in the description that the TC
> should not be used for new MIB's.
>
> It is just the RFC3811 with the change. the authors as well as you and
> Thomas are greatly acknowledged for your help.
>
> Thanks again,
> Vishwas
>
> On Tue, Jun 3, 2008 at 7:17 AM, Adrian Farrel <[email-masked]> wrote:
>> Hi Vishwas,
>>
>> I guess I didn't complete the thread that you reference.
>>
>> Updating MIBs is a real pain in the rump. It is as bad as completely
>> changing the meaning in a wire protocol because you will create all manner
>> of interoperability issues.
>>
>> It may be OK for new implementations, but it will be very hard for SNMP
>> applications that need to talk to different routers, and for routers that
>> need to talk to different SNMP applications.
>>
>> A solution in this case might be to extend the MIB module such that if the
>> MIB extension table is present it supersedes the old objects used to carry
>> extended tunnel IDs. But, this still only addresses 75% of the use cases
>> (up-level talks to up-level, back-level talks to back-level, and back-level
>> talks to up-level). It does not address up-level talks to back-level (half
>> of this would throw a fault if an up-level application tried to SET the new
>> object, but the other half would go unnoticed when an up-level agent
>> supplies the old object with a meaningless value, and the new object is not
>> read by a back-level application).
>>
>> Typically, if a change *really* needs to be made, the whole MIB module is
>> rev'd. This is OK, but causes all implementations to have to decide which
>> they support and which their partners support. That is messy.
>>
>> So we would need to be really sure that our motivation is not just
>> "completeness" but real deployment issues.
>>
>> Cheers,
>> Adrian
>>
>> ----- Original Message ----- From: "Vishwas Manral" <[email-masked]>
>> To: "Thomas Nadeau" <[email-masked]>
>> Cc: <[email-masked]>
>> Sent: Tuesday, June 03, 2008 2:00 AM
>> Subject: Re: [mpls] RFC3815
>>
>>
>>> Hi Thomas,
>>>
>>> Thanks for the mail, I will read the document you mention and
>>> understand the details further.
>>>
>>> The biggest issue I have found is with the RFC3811. The basic TC is wrong.
>>>
>>> Checkout the conversation with Adrian
>>> http://www.ietf.org/mail-archive/web/mpls/current/msg02073.html . I
>>> think I will work to update the MIB sometime soon.
>>>
>>> Thanks,
>>> Vishwas
>>>
>>> On Tue, Jun 3, 2008 at 12:14 AM, Thomas Nadeau <[email-masked]>
>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> It seems to me that we may need to update the LDP MIB, based on
>>>>> changes in the LDP RFC.
>>>>>
>>>>> As we can have the same LDP instance running IPv4 as well as IPv6, we
>>>>> need to have different mplsLdpEntityTransportAddrKind  for IPv4 and
>>>>> IPv6 as we will have two different transport addresses.
>>>>
>>>>       We have already solved this problem using this approach:
>>>>
>>>>       draft-kkoushik-snmp-context-map-mib-01.txt
>>>>
>>>>> Similarly mplsFecType no longer needs to support the value of
>>>>> HostAddress as it has been obsoleted.
>>>>>
>>>>> Also as we now allow different Hellos for IPv4 and IPv6, we could also
>>>>> have all such information in an LDP adjacency duplicated for IPv4 and
>>>>> IPv6.
>>>>
>>>>       Are there other things missing or that need updating?  The above
>>>> changes
>>>> could be done pretty quickly as an rfc3815bis if they are constrained to
>>>> the
>>>> above.
>>>>
>>>>       --Tom
>>>>
>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Vishwas
>>>>> _______________________________________________
>>>>> mpls mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> mpls mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>
>>
>>
>
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 8 Sep 2008 11:14:27 -0400

Changing the TC will require a re-write of ALL of the RFCs that  
consume it if you change any
of the SMI or any semantics of how the objects are used. Given the  
numerous successful deployments of these
out there now, I am not in favor of having to re-spin all of these.   
There are not perfect, but they do work.

	--Tom

>>> ----- Original Message ----- From: "Vishwas Manral" <[email-masked] 
>>> >
>>>> On Tue, Jun 3, 2008 at 12:14 AM, Thomas Nadeau <[email-masked] 
>>>> >
>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 8 Sep 2008 16:27:33 +0100

Tom,

I believe that the only change in this I-D is to add a new TC.

That is, I did a quick wdiff and that was the only change that jumped out at 
me. Of course there may be others and it would be helpful if the I-D told us 
what was going on! (All it has at the moment is an incomplete sentence in 
the Abstract.)

If the intention is to just define a new TC, why do we need a bis? What 
would be wrong with a separate I-D to contain the TC?

But I also don't think that just defining the new TC will help, will it? The 
TC actually has to be used somewhere. What changes will be made to pick up 
the new TC?

Cheers,
Adrian
----- Original Message ----- 
From: "Thomas Nadeau" <[email-masked]>
To: "Vishwas Manral" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Monday, September 08, 2008 4:14 PM
Subject: Re: [mpls] RFC3815

>
> Changing the TC will require a re-write of ALL of the RFCs that  consume 
> it if you change any
>>>> talks to up-level). It does not address up-level talks to back- level 
>>>> (half

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 8 Sep 2008 21:38:48 +0530

Hi Adrian,

You got it correct. We could have as well have just added a new TC
alone, like I mentioned (and done in the draft). The only other thing
we have currently done  is to obsolete the old TC so that new drafts
are aware (that may not be necessary though  and we could leave both
the TC's).

The MIB's as and when they get updated can use the new TC. By not
updating the TC, the problem can never be corrected.  I do not think
leaving something wrong is the best solution, a better solution could
be to correct the wrong thing, specify that the older thing should no
longer be used (and either obsolete it now or may be later).

Tom,

The MIB's may not need to be updated in the case we just add a new TC.

Thanks,
Vishwas

On Mon, Sep 8, 2008 at 8:57 PM, Adrian Farrel <[email-masked]> wrote:
> ----- Original Message ----- From: "Thomas Nadeau" <[email-masked]>
>> out there now, I am not in favor of having to re-spin all of these. There
>> are not perfect, but they do work.
>>
>> --Tom
>>
>>
>>> Hi,
>>>

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 9 Sep 2008 08:01:12 +0530

Hi Adrian,

One thing I forgot to mention was, that although like you stated we
can have a separate document for the new TC, in my view it would be
better that we have all TC's in the same document.

In my view after reading the issues raised by you and Tom, the bigger
issue we have is should we obsolete the older TC, or should we have
both the TC's (and in the description of the old TC state that this
should not be used for any new MIB's or whenever a MIB update is to
happen).

Thanks,
Vishwas

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 8 Sep 2008 19:27:59 +0530

Hi Adrian,

Thanks again,
Vishwas