Re: [Rift] I-D Action: draft-ietf-rift-yang-09.txt

From: zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>
Sent: 19 September 2023 03:31

Hi Tom,

Thank you very much for your detailed explanation!

According to your comments, the non-zone is a better solution for now.

Though in the future the meaning ip-address with zone in RFC6991 may be changed, right?

If it is, I'll modify the type to non-zone.

<tp>

I think so.  Reading rift.rift I cannot tell whether the addresses require a zone or not.  'zone' is needed with e.g. data center servers with multiple links where the same link local address can appear on multiple links and the zone is needed to tell them apart.  As I say, I am unclear if this applies with multicast protocols.

As to the IETF defined types, I think it safe to assume that the type identifiers with 'zone' or 'no-zone' in them will not change, it is the ones without such as 'ipv4-address' where there is pressure to change the meaning (for the benefit of those who do not read the specifications:-(

Tom Petch

Best regards,

Sandy

<http://www.zte.com.cn/>

<http://www.zte.com.cn/>

Original
From: tompetch <ietfa@btconnect.com>
To: 张征00007940;
Cc: rift@ietf.org <rift@ietf.org>;
Date: 2023年09月15日 17:27
Subject: Re: [Rift] I-D Action: draft-ietf-rift-yang-09.txt
From: zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>
Sent: 15 September 2023 03:20

Hi Tom,

Thank you for your explanation!

Sorry for the late response.  I failed to find the associated discussion you mentioned in the NETMOD mailing list.

According to your point, the non-zone ip-address is more suitable for RIFT YANG.

But I am confused because AFAIK there is no zone in the ip address of OSPF or IS-IS also, but OSPF and IS-IS is still using the ip-address with zone, right?

If OSPF and IS-IS will modify the model?

<tp>
Ther have been many such discussions on the netmod list; one such started  14April2022

Earlier that month there was an extensive discussion about how many authors had used the types as specified in RFC6991 and how many had assumed that they knew what the types were without consulting the RFC; an LSR author was stating that RFC6991 got it wrong and that the definition of the types without -no-zone should be changed to omit the zone which suggests to me that the LSR I-Ds cannot be relied on as an example of best practice.

More generally, I assume that the use of -no-zone type is a conscious decision and that anything else is not (which may be the right decision but we cannot tell).  That said, I think that the inclusion of a zone where the module author did not expect one is unlikely to cause many failures - it may be that the producers of tools and such like cater for this and quietly elide the zone if the value comes with a zone and is being put into a 128-bit field - that is speculation on my part but I do recall when web browsers tested for Microsoft because Microsoft had misunderstood HTML and interpreted some markup differently to anyone else.  Producers of software that customers pay for tend to produce software that works for customers rather than software that fails according to the letter of the RFC.

Some are still agitating to change the meaning in RFC6991-bis which suggests to me that any RFC in error will not be updated soon.

I looked at rift-rift but could not tell if the zone is wanted or not - you will doubtless have a better idea of that than I.  If the zone is not wanted, then specify -no-zone.  I have yet to see anyone suggesting a change of meaning to the -no-zone variants:-)

Tom Petch

Best regards,

Sandy

<http://www.zte.com.cn/>

<http://www.zte.com.cn/>

Original
From: tompetch <ietfa@btconnect.com>
To: 张征00007940;
Cc: rift@ietf.org <rift@ietf.org>;
Date: 2023年09月11日 19:56
Subject: Re: [Rift] I-D Action: draft-ietf-rift-yang-09.txt
From: zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>
Sent: 11 September 2023 01:37

Hi Tom,

The RIFT YANG was updated.

Some terminilogies were added according to your comments.

About the zone in ip-address, we think that there is no special consideration in RIFT after the discussion among co-author.

So we'd like to be align with other IGP protocols, such as OSPF and IS-IS.

<tp>

That may be the blind leading the blind:-(

When this topic, of the default YANG type for ip addresses including the zone, surfaced on the NETMOD list recently, there was much discussion and it was apparent that a number of authors of RFC had not read the specification and had  assumed that an IPv6 address was 128 bit and not 128 bit plus an undefined number of zone characters.  A number of such wanted to make a non-backwards compatible change to RFC6991 so that the
typedef ipv6-address
would no longer include the zone and that those who had read the specification and knew what they wanted would have to go back and produce new RFC, the innocent suffering for their wisdom.

So when you see a specification the 'no-zone' in it I think that it is safe to assume that the authors had read the specification and knew what they wanted; but if you see a specification without the 'no-zone' then I think that you cannot draw the inference that is the correct type.

Sometimes you can tell from the protocol specification.  If the address field is defined as 16 octet, then clearly 'no-zone' is intended.  Looking at rift-rift I cannot tell.

Tom Petch

Thank you for your further review and comments.

Best regards,

Sandy

<http://www.zte.com.cn/>

<http://www.zte.com.cn/>

Original
From: internet-drafts@ietf.org <internet-drafts@ietf.org>
To: i-d-announce@ietf.org <i-d-announce@ietf.org>;
Cc: rift@ietf.org <rift@ietf.org>;
Date: 2023年09月08日 14:39
Subject: [Rift] I-D Action: draft-ietf-rift-yang-09.txt
Internet-Draft draft-ietf-rift-yang-09.txt is now available. It is a work item
of the Routing In Fat Trees (RIFT) WG of the IETF.

   Title:   YANG Data Model for Routing in Fat Trees (RIFT)
   Authors: Zheng Zhang
            Yuehua Wei
            Shaowen Ma
            Xufeng Liu
            Bruno Rijsman
   Name:    draft-ietf-rift-yang-09.txt
   Pages:   45
   Dates:   2023-09-07

Abstract:

   This document defines a YANG data model for the configuration and
   management of Routing in Fat Trees (RIFT) Protocol.  The model is
   based on YANG 1.1 as defined in RFC7950 and conforms to the Network
   Management Datastore Architecture (NMDA) as described in RFC8342.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-rift-yang/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-rift-yang-09

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-rift-yang-09

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts

_______________________________________________
RIFT mailing list
RIFT@ietf.org
https://www.ietf.org/mailman/listinfo/rift

_______________________________________________
RIFT mailing list
RIFT@ietf.org
https://www.ietf.org/mailman/listinfo/rift