[mpls] Re: Early MIB Dr. review of draft-ietf-mpls-p2mp-te-mib-03.txt

["Adrian Farrel" <adrian at olddog.co.uk>]

Thanks Joan,

A new revision to address most of your points has just been submitted.

But a couple of items are discussed below.

You asked:

> > *) Are there any objects which apply only to GMPLS?

There is no difference (at this time) between P2MP MPLS-TE  and P2MP GMPLS. 
All objects can be applied to GMPLS.

> > **) 6.1. Example Use of the LSR MIB Module
> >
> > Even if the LSR MIB is able to be used to configure P2MP,
> > SHOULD it be used?
> > What is the benefit of doing so?
> > Are networks really doing this?
> >
> > My concern is that it is far easier to document one way of configuring a 
> > feature and supporting this way through the standards process than to
> > put forth a secondary way to configure.  So unless there is truly a 
> > compelling reason, why do this?
> >
> > If you want to proceed with the LSR MIB being used for p2mp,
> > then you need to show an example of how to configure this.  Order
> > of the configuration seems critical, and that needs to be explained.

You'll notice that RFC3813 allows write access to the LSR MIB.
So, clearly it was deemed acceptable to manually set up forwarding state (or 
cross-connections). And we must recall that (much as I love the control 
plane) the control plane is not the only way to operate a network. Consider, 
for example, the majority of transport networks.

Now, you'll also note that RFC3813 allows a "cross-connect" to have multiple 
in and out segments.

So I don't think there is anything else to say.

> > *)    mplsTeP2mpTunnelNotificationEnable OBJECT-TYPE
> >
> > Can RFC3413 be used instead?

Do you feel strongly about this?
We could use it, but:
- we should probably follow the same structure as RFC3812
- I don't like forcing the support of another MIB module for this
  one bit (literally) of information.

> > * Why is RFC4461 in the informative section?  Would think this should
> > be in the Normative.

The downref rules are a pain :-) and it is easier to avoid them than deal 
with them.

> Section "4.2 Use of MPLS-TE-STD-MIB".
>
> There was concern that using the same Objects with updates from
> MPLS-TE-STD-MIB would result in a backwards compatibility
> issue.  (If the situation came about that there were devices that 
> supported
> the original version of the MPLS-TE-STD-MIB and a newer version, then
> the interpretation of these objects might be confused.
> The suggestion was to create new objects in this MIB.
> Also, it would be necessary to include in the conformance section
> of the MIB what objects from MPLS-TE-STD-MIB need to
> be supported.

I don't see any backward compatibility issues.
Legacy implementations do not support the P2MP MIB module, so do not have a 
problem.
The functional change is to interpret certain objects in MPLS-TE-STD-MIB 
differently if (and only if) there is a corresponding row entry in 
mplsTeP2mpTunnelTable.

If we created new objects in MPLS-TE-P2MP-STD-MIB (which we could) then we 
would still need to change the interpretation of the objects in 
MPLS-TE-STD-MIB because they would cease to be meaningful. Having decided 
that we had to change the interpretation, we decided that we would not also 
need new objects.

What do you think?


Once again, many thanks.

Adrian 




_______________________________________________
mpls mailing list
mpls at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls