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

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 7 Jul 2007 21:07:42 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: "Joan Cucchiara" <[email-masked]>
Date: Thu, 12 Jul 2007 23:49:46 -0400

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: "Joan Cucchiara" <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Cc: "Romascanu, Dan (Dan)" <[email-masked]>; "Loa Andersson" 
<[email-masked]>; <[email-masked]>
Sent: Saturday, July 07, 2007 4:07 PM
Subject: Re: Early MIB Dr. review of draft-ietf-mpls-p2mp-te-mib-03.txt

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

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

Okay, I see your point.  If order of configuration is important then please 
include
an example of the p2mp using the LSR MIB.

>   one bit (literally) of information.

Okay...being consistent with RFC3812 is reasonable.

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

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.

> Legacy implementations do not support the P2MP MIB module, so do not have 
> a problem.

Legacy NMSs would have an issue.

> differently if (and only if) there is a corresponding row entry in 

A legacy NMS would have no knowledge of this and thus, interpret values 
based
on the original meaning of the object.

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

> Once again, many thanks.

Thanks also!  This early MIB review has generated some good discussions.

Thanks,
  -Joan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 17 Jul 2007 00:18:45 +0200

> -----Original Message-----
> From: Joan Cucchiara [mailto:[email-masked]] 
> 
> >
> >>> * 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.
> >
> 

The proper thing to do in my opinion is to mention the down-ref in the
IETF Last Call, as per RFC 3967.

Dan

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 17 Jul 2007 15:07:40 +0100

Hi Joan,

Converging...

> Could this be stated in the document?

OK

>>>> **) 6.1. Example Use of the LSR MIB Module
[SNIP]
> 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.

> when the document goes to IETF Editor?   Perhaps, the downref rules will

Well, OK.

But it will all end in tears.

> 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 change meaning (i.e. a semantic change to the
> object) when using MPLS-TE-P2MP-STD-MIB, then
> semantically and adding new objects to the MPLS-TE-STD-MIB
> module....)
>
> 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

---

From: "Joan Cucchiara" <[email-masked]>
Date: Sun, 22 Jul 2007 22:47:48 -0400

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: "Joan Cucchiara" <[email-masked]>; 
Sent: Tuesday, July 17, 2007 10:07 AM

>>> The downref rules are a pain :-) and it is easier to avoid them than 
>>> deal with them.
>>
>>> Legacy implementations do not support the P2MP MIB module, so do not 
>>> have a problem.
>>
>>> 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?
>>
> 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.

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

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.

>  will be successful, but the value (i.e. the object) will be ignored by

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

>  will be successful, but the value (i.e. the object) will be ignored by

same question about management agent.

> 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