Subject: RE: [MIB-DOCTORS] RE: use of TransportDomain/Address (RFC3419) vsTDomain/TAddres s (RFC2579)

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 28 Dec 2006 08:13:22 +0200

I believe that the discussion in (3) is important and should be
conducted maybe as part of the multiprotocol management framework
discussions which we should have rather sooner than later in the area. 

I would however not delay recommending (2) for the IEEE 802.1ag MIB work
because 93) is not going to get resolved that soon, and 802.1ag has a
schedule to meet, of course while documenting the rationale and the
constraints involved with this solution. 

Dan

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Wednesday, December 27, 2006 6:58 PM
> To: Wijnen, Bert (Bert)
> Cc: MIB Doctors (E-mail)
> Subject: Re: [MIB-DOCTORS] RE: use of TransportDomain/Address 
> (RFC3419) vsTDomain/TAddres s (RFC2579)
> 
> Bert,
> 
> I believe the discussion is not clear since I do not know 
> from the MIB fragment below whether a fault alarm destination 
> is an SNMP notification receiver or something else.
> 
> (1) If it is an SNMP notification receiver, I believe the notification
>     target mechanisms should be used.
> 
> (2) If that is impossible (should perhaps be documented why), then
>     TDomain/TAddress are appropriate addressing constructs since they
>     are used throughout the SNMP MIB modules and all the existing or
>     work-in-progress transports will be compatible with 
> TDomain/TAddress.
> 
> (3) If, however, the idea is to identify a transport endpoint for
>     arbitrary management interfaces that can carry notifications
>     (SNMP, SYSLOG, NETCONF), then I believe the situation is far less
>     clear since we never really discussed how you specify such an
>     endpoint which can cross multiple protocols. My preference in this
>     case would be URIs, e.g.  SNMP service URIs as defined in RFC 4088
>     but then I am sure there are other opinions and discussion is
>     needed.
> 
> Perhaps this helps to understand the scope of the discussion.
> 
> /js
> 
> On Wed, Dec 27, 2006 at 03:23:19PM +0100, Wijnen, Bert (Bert) wrote:
> > Remember below discussion?
> > 
> > Meanwhile not much discussion has taken place here, but 
> quite a bit on 
> > IEEE mailing lists and between various people who showed a close 
> > interest to participate.
> > 
> > In any event, right now, it seems (or so Dan and I have concluded) 
> > that following juergens advise to use TDomain and TAddress  is the 
> > best path and seems to be the consensus... (even though not so many 
> > people participated).
> > 
> > So the advise to the 802.1ag folks will now be to use 
> TDomain/Address 
> > instead of TransportDoman/Address.
> > 
> > Bert
> > 
> > > -----Original Message-----
> > > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > > Sent: dinsdag 5 september 2006 22:29
> > > To: MIB Doctors (E-mail)
> > > Subject: [MIB-DOCTORS] Help: use of TransportDomain/Address
> > > (RFC3419) vs TDomain/TAddres s (RFC2579)
> > > 
> > > I have been discussing this off-line somewhat with Juergen.
> > > He needs to do a reread of 3419 to make up his mind.
> > > 
> > > I would like to see if we have (or can come to) 
> mib-doctor consensus 
> > > on this. I am advising the 802.1ag MIB editors and have currently 
> > > this proposal described below.
> > > 
> > > However, Juergen has hinted that it may be better toi use 
> > > TDomain/Taddress SYNTAX instead. Or if we stick to this, 
> we may have 
> > > to add something to the DESCRIPTION clauses that this is for SNMP 
> > > messages and so needs to comply with SNMP semantics (as 
> described in 
> > > the Transport-Mapping for SNMP).
> > > 
> > > Comments?
> > > 
> > > Betr
> > > 
> > > ---- the proposal:
> > > 
> > > dot1agCfmMdFaultAlarmDestDomain OBJECT-TYPE
> > >     SYNTAX      TransportDomain
> > >     MAX-ACCESS  read-create
> > >     STATUS      current
> > >     DESCRIPTION
> > >        "The transportDomain for the address to which Fault Alarms
> > >         are to be transmitted.
> > > 
> > >         Typical values will be one of (not all inclusive) list:
> > > 
> > >            transportDomainUdpIpv4  (from TRANSPORT-ADDRESS-MIB)
> > >            transportDomainUdpIpv6  (from TRANSPORT-ADDRESS-MIB)
> > >            snmpIeee802Domain       (from SNMP-IEEE802-TM-MIB)
> > > 
> > >         The value 'zeroDotZero' indicates 'Fault Alarms are not to
> > >         be transmitted', in which case the related object 
> of SYNTAX
> > >         TransportAddress must have a zero-length OCTET STRING as
> > >         a value.
> > >        "
> > >     REFERENCE
> > >        "802.1ag clause 12.14.5.1.3 d)"
> > >     DEFVAL { zeroDotZero }
> > >     ::= { dot1agCfmMdEntry 6 }
> > > 
> > > dot1agCfmMdFaulAlarmDestAddress OBJECT-TYPE
> > >     SYNTAX      TransportAddress
> > >     MAX-ACCESS  read-create
> > >     STATUS      current
> > >     DESCRIPTION
> > >        "The transportAddress to which Fault Alarms are to be
> > >         transmitted to. The type/format of this object is 
> determined
> > >         by the value of the dot1agCfmMdFaultAlarmDestDomain.
> > > 
> > >         If the dot1agCfmMdFaultAlarmDestDomain object has 
> a value of
> > >         'zeroDotZero' (indicating 'Fault Alarms are not to be
> > >         transmitted') then this object should have a value of a
> > >         zero-length OCTET STRING.
> > >        "
> > >     REFERENCE
> > >        "802.1ag clause 12.14.5.1.3 d)"
> > >     DEFVAL { "" }
> > >     ::= { dot1agCfmMdEntry 7 }
> > > 
> > > _______________________________________________
> > > MIB-DOCTORS mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/mib-doctors
> > > 
> > 
> > _______________________________________________
> > MIB-DOCTORS mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mib-doctors
> 
> -- 
> Juergen Schoenwaelder		 {International|Jacobs} 
> University Bremen
> <http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 
> 28725 Bremen, Germany
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mib-doctors
> 

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Dec 2006 09:47:36 +0100

> constraints involved with this solution. 

Perhaps you can clarify the following:

(a) Does 802.1ag really want to address arbitrary management
    interfaces?

(b) If yes, what specific protocols do they have in mind (or do they
    really don't know)?

(c) If no, why does (1) not work.

I believe it is important to have a clear description of the situation
if you seek advice from MIB doctors. I suppose the majority on this
list is likely not as closely involved in IEEE 802.1ag as you (and
Bert) likely are.

/js

-- 
Juergen Schoenwaelder		 {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany