Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base

Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> Wed, 09 December 2020 17:56 UTC

Return-Path: <muthu.arul@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B49A3A16CB for <lsr@ietfa.amsl.com>; Wed, 9 Dec 2020 09:56:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.854
X-Spam-Level:
X-Spam-Status: No, score=-0.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnHv2n6Il5Xw for <lsr@ietfa.amsl.com>; Wed, 9 Dec 2020 09:56:42 -0800 (PST)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55CC23A168D for <lsr@ietf.org>; Wed, 9 Dec 2020 09:56:42 -0800 (PST)
Received: by mail-lf1-x135.google.com with SMTP id y19so4259552lfa.13 for <lsr@ietf.org>; Wed, 09 Dec 2020 09:56:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v+ESjWxXC8xWTiITkCZ2+Ghd+W7lW2Z21Nv5MR3cl+I=; b=QLHdRvGLpqKWn6lAAOF3yRSCnwwEzIkQB70nLSv+ZArFKysui3nsmnuOh9/059foo1 SPvGxqFRP0eEMbFYbkkPB1bpIwyHo9ld3skZdSWIsCnPy0GgR6ggfSwAPLQLG/f6rejY Cn1GWlw9IK4lnkoUUc2UhnXJJALyo3ohwDM14DJHO3y59XqG/u3fcb2zZ1yPb+cPdqPM pNDfvZiMcAfkknfvn6S5QOK4biiDby0Wh5NKaObi497U4LgjkgdAXmdWUfYQP20VjUhb T/oJyhznaN6H8FAS5un/IOKvpItWYtz4wEeajvkYBZQLKjmuiyTxvJhZQYgBIgcHMcc3 iRQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v+ESjWxXC8xWTiITkCZ2+Ghd+W7lW2Z21Nv5MR3cl+I=; b=IBnuhX86UsyRCzaQpPtjh5xjaTjsOqRRvO3C48LfZWFhOaib9JD78lz0RLJ3NYCVGp VBQKLPw93wYtnTjbgIZtxaFNSXksjGkkRwsXr2UYtkpZwM/JEDdEuLQHyPTST8oG3lWu DgjUkwuocCq8kL53Lyvuo7y91uplXTBeW9gUFkH+MspxPcyNQZDGBLJxyRCMtfCIHGrW Xr2ujkbye5aInm9sGoTG7cOAIRZf+gd4x+w2bChQKdyr/BcLWkvcapTPHD/FnAgepGVG VrlRLroDhYkS4JpgxoGBzMa50YiYHCLhD3f3Cou8TFBhqCvYaOFphlpoQWGocW/b4C/J LUfQ==
X-Gm-Message-State: AOAM531C0YavTagj35WJi0i8HJbqVT8+utb2qRw4pLdfImpporNcFQ1T 65S4H/G3P17FWg8RBC8WcMJxnfu/KpGtZMW0Lck=
X-Google-Smtp-Source: ABdhPJxVVI+9O8Su8aXRSuN5aR8RgWgMyKYf2gC6sUmaPgQkUF+mYTn0XJNlW/oXOMgx80ClgyZwXcUoWUPnpVDdpvg=
X-Received: by 2002:a05:6512:318f:: with SMTP id i15mr1470693lfe.385.1607536600330; Wed, 09 Dec 2020 09:56:40 -0800 (PST)
MIME-Version: 1.0
References: <CAJePrfdqbZ0anJgM_aMwArYr3Qm0YkoraTHMOV4XaqyZQ0+BcA@mail.gmail.com> <CAJePrfd15wLm1pW+sgHwV+JbA8Yq2hQ34B4jGzhTYJFBRbopzQ@mail.gmail.com> <44447C51-58FA-4756-92A0-BD0DBC26E44D@cisco.com> <CAKz0y8wNP4ip==2P9GGNc2H68GKQB38ZQi+bG_4xF-uuR8b4EQ@mail.gmail.com> <0F281788-1B38-48FF-B8C0-0348DA388571@cisco.com> <CAKz0y8wFjFnxu3uBpO8HLfNis9M+qPQGUkTYEKMVL6Kmcjw+sA@mail.gmail.com> <2958A5A6-5213-4B5E-B893-F9B874240F3B@cisco.com>
In-Reply-To: <2958A5A6-5213-4B5E-B893-F9B874240F3B@cisco.com>
From: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
Date: Wed, 9 Dec 2020 23:26:28 +0530
Message-ID: <CAKz0y8wRC-Fgh=o0Wj8LfwCuPGh001oevfD5e296HSTB0T7Zjw@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, Tulasi Rami Reddy N <tulasi.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000006b4a205b60bc864"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/LQPkwR2F8gz6o_F1UERLoQMLokA>
Subject: Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Dec 2020 17:56:45 -0000

Thanks, Acee. I thought about the ospfIfConfigError trap with the noError
code. Would have been nice if noError was defined as 255 with 13 to 254
defined for future definitions, but that ship already sailed far and out :)

Regards,
Muthu

On Wed, Dec 9, 2020 at 8:52 PM Acee Lindem (acee) <acee@cisco.com> wrote:

> Hi Muthu,
>
> In that case, I would just send ospfIfRxBadPacket – it contains the local
> and remote IP addresses in the trap data. Or, you could use ospfIfConfigError
> and you could set the error to noError since there isn’t one explicitly
> defined for this situation.
>
> Good Luck,
>
> Acee
>
>
>
>
>
>
>
> *From: *Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
> *Date: *Wednesday, December 9, 2020 at 8:51 AM
> *To: *Acee Lindem <acee@cisco.com>
> *Cc: *"Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>rg>, "
> lsr@ietf.org" <lsr@ietf.org>rg>, Tulasi Rami Reddy N <tulasi.ietf@gmail.com>
> *Subject: *Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base
>
>
>
> Hi Acee,
>
>
>
> We aren't generating any trap today for the subnet mismatch case. We
> wanted to get some feedback on what would be an appropriate trap to
> generate from a usability standpoint, if we want to generate one..
>
>
>
> Regards,
>
> Muthu
>
>
>
> On Wed, Dec 9, 2020 at 7:09 PM Acee Lindem (acee) <acee@cisco.com> wrote:
>
> Hi Muthu,
>
> There isn’t a specific case for this specific error so I wouldn’t reuse
> the any of the specific ones with the trap. Like I said, some
> implementations don’t generate any OSPF MIB trap for this case. What are
> you doing today?
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr <lsr-bounces@ietf.org> on behalf of Muthu Arul Mozhi Perumal <
> muthu.arul@gmail.com>
> *Date: *Wednesday, December 9, 2020 at 8:18 AM
> *To: *"Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
> *Cc: *"lsr@ietf.org" <lsr@ietf.org>rg>, Tulasi Rami Reddy N <
> tulasi.ietf@gmail.com>
> *Subject: *Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base
>
>
>
> Hi Acee,
>
>
>
> This is a configuration error, right? Wouldn't ospfIfConfigError trap be
> more appropriate? There is no good error code for this case
> in ospfConfigErrorType, though. Perhaps, RFC4750 could have reserved some
> error codes for future definitions?
>
>
>
> Regards,
>
> Muthu
>
>
>
> On Wed, Dec 9, 2020 at 6:16 PM Acee Lindem (acee) <acee=
> 40cisco.com@dmarc.ietf.org> wrote:
>
> Hi Tulasi,
>
> You definitely shouldn’t generate the netMaskMismatch trap as this is for
> mask mismatch detection on hello packets. You could generate the
> ospfIfRxBadPacket but many do not for this case.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr <lsr-bounces@ietf.org> on behalf of Tulasi Rami Reddy N <
> tulasi.ietf@gmail.com>
> *Date: *Wednesday, December 9, 2020 at 6:11 AM
> *To: *"lsr@ietf.org" <lsr@ietf.org>
> *Subject: *Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base
>
>
>
> [ Sorry, My previous mail was truncated]
>
> Hi ,
>
>
>
> OSPFv2 adjacency will be formed on a numbered LAN only below both
> conditions are met:
>
>            1. Common IP subnet
>
>            2. Matching network mask.
>
> From the OSPFv2 MIB, there is only one error defined.
>
>
>
>      ospfConfigErrorType OBJECT-TYPE
>           SYNTAX       INTEGER {
>
>                           *netMaskMismatch (7),*
>            }
>
>
>
> I believe this is for the case 2 (when mask is mismatched).
>
>
>
> Let's take below example:
>
>
>
>   RTA    (11.1.1.2/24)   --------     (10.1.1.1/24) RTB
>
>
>
> Here, src IP is not matching to the Rx interface IP subnet, then what is
> the error type to be set?
>
> Should this be considered as generic input processing error and
> only generate
>
> *ospfIfRxBadPacket *notification or *netMaskMismatch  *notification?
>
> Should we need a new type here?
>
>
>
> "
>
> The generic input processing of OSPF packets will
>
> have checked the validity of the IP header and the OSPF packet
>
> header."
>
>
>
>
>
>
>
> Thanks,
>
> Tulasi.
>
> On Wed, Dec 9, 2020 at 4:27 PM Tulasi Rami Reddy N <tulasi.ietf@gmail.com>
> wrote:
>
> Hi ,
>
>
>
> OSPFv2 adjacency will be formed on a numbered LAN only when
>
>            1. Common IP subnet
>
> 2.matching network mask.
>
> From the
>
>
>
> Thanks,
>
> TUlasi.
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>