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

----- Original Message ----- 
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Joan Cucchiara" <jcucchiara@mindspring.com>; 
<s.yasukawa@hco.ntt.co.jp>; <tnadeau@cisco.com>
Cc: "Romascanu, Dan (Dan)" <dromasca@avaya.com>; "Loa Andersson" 
<loa@pi.se>; <mpls@ietf.org>
Sent: Tuesday, July 17, 2007 10:07 AM
Subject: Re: Early MIB Dr. review of draft-ietf-mpls-p2mp-te-mib-03.txt

> 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.

Also,  need to consider scripts and tools which are based on the 
MPLS-TE-STD-MIB.

>
> So we must first agree that there is no practical way that the legacy 
> management station can create the P2MP TE tunnel.

Regardless, if the routers are updated with software that supports both MIBs 
(and seems likely
that vendors would support both MIBs for some time) and if someone wants
the P2MP feature then P2MP can be configured by other
means (not necessarily the NMS).

> 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.

What you write above seems contractory to the description in the
draft, specifically, "but for a P2MP tunnel, this object does not
      identify an address of the egress of the tunnel. Instead it
      contains the P2MP ID value that identifies the identifier of the
      set of destinations for the P2MP tunnel and is carried in the P2MP
      Session Object [RFC4875]. "

The p2p  value is found in the RSVP-TE session object, and the p2mp value
is from a different session object, so I am under the impression that a read 
of
this object for p2mp could be misleading/confusing.

> 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.
>

What is the "management agent"?  Are you referring to the SNMP agent, or the
SNMP manager?

> 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.
>

same question about 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?
>

Few more questions (asked above) before I can answer.

Thanks,
  Joan

> Thanks,
> Adrian
>
>
>
>
>
>
>
>
>
>
> 

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