I really like the way the RFC 4940 OSPF registries is a one stop shop and
has all the bit flags for both OSPFv2 and OSPFv3 that can be referenced for
all RFCs.
Nice!!
Great sanity check and helps when reading RFCs as well as I think for IETF
protocol development adding new flags or updating
Hi all,
I support the adoption of this draft.
I reviewed this draft-xie-lsr-isis-sr-vtn-mt-03 and I think this draft
describes a good use case which realizes VPN+ by using existing IS-IS
extensions such as Multi-Topology, SR, and TE.
Thanks,
Takuya
On 2021/03/03 8:27, Acee Lindem (acee)
Adding the bit registries when there is extension for the defined flag field is
helpful for reviewing the related IETF documents.
For newly defined flag field, such policy can also apply considering there
maybe no bit extensions for some flag field.
And, should this action be discussed in
Speaking as WG member:
Hi Les,
My opinion is there is no harm and some advantage in having IANA registries for
unique IGP protocol bit flag fields. For the existing fields that don’t have
registries, there is no burning requirement to go back and define an IANA
registry until such time as that
Tony –
In this context I don’t find the use of a registry of value. The primary issue
for me for these fields is not managing the bit assignments but understanding
the functionality – and for that I need to look at the document(s) which have
that definition. A registry in these cases provides
Les,
> IMO, there is no need for registries for the first category. The WG has been
> alive for over 20 years, defined many new TLVs with flags fields, and I am
> not aware of any confusion – so if it ain’t broke don’t fix it.
With all due respect Les, you appear to operate with an eidetic
From: Lsr on behalf of Tony Li
Sent: 17 March 2021 20:56
Les,
[Les:] The question here is whether there is a qualitative difference between
two classes of bit fields.
That is indeed the key question. IMHO, there is not.
I don’t much care if a field is updated by a bis document or a related
Hi Xuesong,
Thanks for your support.
Regarding your comment about the overlay and underlay network, in this context
the overlay refers to the VPN overlays which provide the service connectivity,
and the underlay refers to the set of network topology and resources provided
using VTNs. We
Hi WG,
I support the adoption of this informational document.
The combination of IS-IS MT with TE extensions allows to build VTNs with
customized topology and link attributes, and SR SIDs are used to steer traffic
using the topologies and resources of each VTN. This mechanism is clear and
