Subject: [mpls] RFC3815

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 2 Jun 2008 11:59:55 +1000

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.

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.

Thanks,
Vishwas
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 2 Jun 2008 10:14:30 -0400

> 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

> have all such information in an LDP adjacency duplicated for IPv4 and

	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

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 3 Jun 2008 11:00:47 +1000

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:
> could be done pretty quickly as an rfc3815bis if they are constrained to the
> above.
>
>        --Tom
>
>
>>
>>
>> Thanks,
>> Vishwas

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 3 Jun 2008 02:47:20 +0100

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