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

["Adrian Farrel" <[e-mail]>]

Hi Joan,

Converging...

>>>> *) 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.
>
> Could this be stated in the document?

OK

>>>> **) 6.1. Example Use of the LSR MIB Module
[SNIP]
>> So I don't think there is anything else to say.
>
> Okay, I see your point.  If order of configuration is important then 
> please include an example of the p2mp using the LSR MIB.

Well, that really is what section 6.1 does.

>>>> * 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.
>
> Could you move the reference to Normative and worry about the downref 
> rules
> when the document goes to IETF Editor?   Perhaps, the downref rules will
> work themselves out.

Well, OK.

But it will all end in tears.

>>> 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.
>
> Legacy NMSs would have an issue.
>
>> 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.
>>
>
> A legacy NMS would have no knowledge of this and thus, interpret values 
> based on the original meaning of the object.
>
>> 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?
>
> I think if you consider a legacy NMS scenario, then the potential exists 
> for
> backwards compatibility problems.   More importantly, if the objects in 
> MPLS-TE-STD-MIB change meaning (i.e. a semantic change to the
> object) when using MPLS-TE-P2MP-STD-MIB, then
> RFC3812 (MPLS-TE-STD-MIB) should be updated to reflect the semantic
> changes.   (For example, maybe deprecating the objects that change 
> semantically and adding new objects to the MPLS-TE-STD-MIB
> module....)
>
> RFC1902 (section 10.2) describes what changes can take place to objects 
> that
> do not semantically change the meaning of the object.
>
> I am happy to consult with the other MIB Doctors on this, in the event 
> that they see something I don't, but it certainly seems that you are 
> saying, that MPLS-TE-STD-MIB has some objects which will change 
> semantically.  Is there anyway that you could add new objects to
> MPLS-TE-P2MP-STD-MIB and not make semantic changes to
> MPLS-TE-STD-MIB?

I understand the intent of your issue, but not the practical impact.

You are worried about what would happen if a legacy management station 
attempted to read the details of a P2MP TE tunnel by looking at its entry in 
MPLS-TE-STD-MIB. You are concerned that it would become confused, report 
incorrect information, or otherwise have problems.

So we must first agree that there is no practical way that the legacy 
management station can create the P2MP TE tunnel. That means that all we 
actually have to do is protect the management station against reading the 
objects of MPLS-TE-STD-MIB that have changed semantics. The two issues are:
1. Read/display will be broken or confused
2. Attempt may be made to manage the P2MP tunnel as if it was a P2P tunnel

Let us look at the objects with changed semantic one by one referring to 
section 4.2 of the I-D.

mplsTunnelMaxHops
   If examined by or set a legacy system, this object will be correctly
   interpreted.

mplsTunnelEgressLSRId
   If a P2MP tunnel is examined by a legacy system, this object will be
   correctly interpreted in that the value will reflect the content of the
   signaling field.
   A legacy system that was used to modify this object for a P2MP
   tunnel would be successful and would not damage the operation of
   the P2MP tunnel.

mplsTunnelHopTableIndex
  If a P2MP tunnel is examined by a legacy system, this object will
  report zero giving the impression that no tunnel hops have been
  configured.
  If this object is set for a P2MP tunnel by a legacy system, the SET
  will be successful, but the value (i.e. the object) will be ignored by
  the management agent.

mplsTunnelPathInUse
  If a P2MP tunnel is examined by a legacy system, this object will
  report zero giving the impression that no path is in use or available.
  If this object is set for a P2MP tunnel by a legacy system, the SET
  will be successful, but the value (i.e. the object) will be ignored by
  the management agent.

mplsTunnelARHopTableIndex
  If a P2MP tunnel is examined by a legacy system, this object will
  report zero giving the impression that no tunnel hops have been
  reported by the signaling protocol. This is a valid scenario.
  This object is read-only and cannot be set.

mplsTunnelCHopTableIndex
  If a P2MP tunnel is examined by a legacy system, this object will
  report zero giving the impression that no tunnel hops have been
  computed. This is a valid scenario.
  This object is read-only and cannot be set.


Would it help to include this sort of text in the I-D, or do you believe we 
cannot make these semantic changes?

Thanks,
Adrian













_______________________________________________
mpls mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mpls