Re: [babel] proposed info model change

"STARK, BARBARA H" <bs7652@att.com> Fri, 26 February 2021 22:22 UTC

From: "STARK, BARBARA H" <bs7652@att.com>
To: 'Juliusz Chroboczek' <jch@irif.fr>
CC: 'Mahesh Jethanandani' <mjethanandani@gmail.com>, 'David Schinazi' <dschinazi.ietf@gmail.com>, 'Toke Høiland-Jørgensen' <toke=40toke.dk@dmarc.ietf.org>, "'babel@ietf.org'" <babel@ietf.org>
Thread-Topic: [babel] proposed info model change
Thread-Index: AdcAt7RXNVd/4GG3Sr6eZ25X+veoLAAAvs0AAABUpAAAAVQxgAAKytMAAAXOZYAAEdtlkALKjGcAAAYDEVA=
Date: Fri, 26 Feb 2021 22:22:43 +0000
Message-ID: <DM6PR02MB69242CA2105EFB93F7C1FD72C39D9@DM6PR02MB6924.namprd02.prod.outlook.com>
References: <DM6PR02MB6924E3E2DD5568E247859E18C38C9@DM6PR02MB6924.namprd02.prod.outlook.com> <87blcqpau7.fsf@toke.dk> <E5F69D0C-7130-42D3-9080-C2EE5786D917@gmail.com> <878s7up8n0.fsf@toke.dk> <CAPDSy+6YWPr81uKHrWYoY=TZ0A18A_Ui3=CyLP=1K-ezwmgF-g@mail.gmail.com> <DBBE09E1-F407-4B5A-A096-669E74F25FB4@gmail.com> <DM6PR02MB69249CEAAB32A391274A8ED3C38B9@DM6PR02MB6924.namprd02.prod.outlook.com> <87eeh2iq9t.wl-jch@irif.fr>
In-Reply-To: <87eeh2iq9t.wl-jch@irif.fr>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5d1e396a-c52d-4b4f-dada-08d8daa509b6
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2021 22:22:43.8759 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6SDt+7463Kpv+RvXEa5KxA5+6F+nNl2k5Fte4D1TwILDDvAcpLEwf/LlCYmXEqqp
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB4411
X-OriginatorOrg: att.com
X-TM-SNTS-SMTP: 5CE1F9978870ECC2EDD6FF6F27E03AEC596F48B4EACB74E3E636F049E10D928F2
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-02-26_09:2021-02-26, 2021-02-26 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 mlxscore=0 clxscore=1015 suspectscore=0 adultscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxlogscore=999 lowpriorityscore=0 priorityscore=1501 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102260163
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/jIheRAzLt1SyE8izdUgs-bi070g>
Subject: Re: [babel] proposed info model change
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Feb 2021 22:22:55 -0000

Hi Juliusz,
We actually ended up figuring out that YANG didn't need to use it as a unique key and we removed all constraints in the -13 revision. It's a read-only parameter, so it's totally up to the Babel implementation to set a value. And the info / data models won't care or police.
Barbara

> > An enabled Babel instance (that is sending and receiving Babel packets) already
> > has a requirement for unique non-zero router-id. Where we were having a
> problem
> > was with not-enabled Babel instances that weren’t actively running the
> protocol
> > (had maybe just been installed). I think it was babeld that was just using a
> > default of all zeroes until it was enabled; at which time it generated its
> > unique router-id. With this not-enabled “zero” default, the possibility exists
> > for multiple not-enabled Babel instances to be defaulted to zero, which would
> > lead to YANG having a problem with having a unique router-id to identify them
> > by.
> 
> It's not an implementation problem, it's a protocol issue.
> 
> In the protocol, the router-id only appears on the wire when a router
> redistributes (originates) a route.  If a router is not originating
> routes, because it is only connected to transit networks, it does not need
> a router-id.
> 
> So in this case, the information model would be imposing a slightly
> stronger requirement on implementations than the core protocol: in order
> to implement the information model, a router would need to draw a router-id
> for itself even if it is only connected to transit networks.
> 
> I don't find this requirement too onerous, and I don't mind the
> information model making it.
> 
> -- Juliusz

[babel] proposed info model change STARK, BARBARA H
Re: [babel] proposed info model change Toke Høiland-Jørgensen
Re: [babel] proposed info model change Mahesh Jethanandani
Re: [babel] proposed info model change Toke Høiland-Jørgensen
Re: [babel] proposed info model change David Schinazi
Re: [babel] proposed info model change Mahesh Jethanandani
Re: [babel] proposed info model change STARK, BARBARA H
Re: [babel] proposed info model change David Schinazi
Re: [babel] proposed info model change STARK, BARBARA H
Re: [babel] proposed info model change Mahesh Jethanandani
Re: [babel] proposed info model change STARK, BARBARA H
Re: [babel] proposed info model change Mahesh Jethanandani
Re: [babel] proposed info model change STARK, BARBARA H
Re: [babel] proposed info model change Mahesh Jethanandani
Re: [babel] proposed info model change Juliusz Chroboczek
Re: [babel] proposed info model change Juliusz Chroboczek
Re: [babel] proposed info model change STARK, BARBARA H