Hi Acee,
On 15/12/2022 14:45, Acee Lindem wrote:
Hi Peter,
On Dec 15, 2022, at 8:11 AM, Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org>
wrote:
On 15/12/2022 13:51, John Scudder wrote:
Thanks, Peter.
Doesn’t this mean that the OSPFv3 draft needs to create its own registry for
the flags, then?
it does.
Section 2 defines the flags field in the OSPFv3 SR capabilities TLV. I don’t
see an IANA registry defined for these flags.
agreed, but I do not have a pen on this draft.
thanks,
Peter
Thanks,
Acee
thanks,
Peter
—John
P.S.: I see 8 instances of “ISIS” in version 19 of isis-srv6, but maybe you’re
looking at the RFCEd version.
On Dec 15, 2022, at 6:29 AM, Peter Psenak <ppse...@cisco.com> wrote:
John,
On 14/12/2022 22:59, John Scudder wrote:
Hi Authors, WG,
As part of my review of draft-ietf-idr-bgpls-srv6-ext-12 I was looking at these
documents and came up with a few comments that would otherwise become part of
my AD review for ospfv3-srv6-extensions, so I thought I’d share them now.
draft-ietf-lsr-isis-srv6-extensions-19 is currently in RFC-EDITOR state so it
may or may not be reasonable to make any changes, but I’m going to mention them
below anyway. I’m sorry I didn’t notice this before we got through IESG review.
draft-ietf-lsr-ospfv3-srv6-extensions-08 Section 2 defines the flags field in a
way that (as per usual) conveniently happens to be identical to how the IS-IS
document defines it. However, I don’t see any language in
draft-ietf-lsr-ospfv3-srv6-extensions-08 saying that the IANA Registry from the
IS-IS draft MUST be used for the assignment of flags for the OSPFv3 field.
Shouldn’t you say this?
we kept the ISIS and OSPF SRv6 capabilities separate. One day they may
diverge.
Also, the registry should probably refer back to both (all three, if we include
the BGP-LS one, but that's another story) specs that make assignments from it,
shouldn’t it? So where the IS-IS document says,
"This document requests a new IANA registry be created under the IS-IS TLV
Codepoints registry to control the assignment of bits 0 to 15 in the Flags field of the
ISIS SRv6 Capabilities sub-TLV specified in this document (Section 2):"
Maybe it should add something like “… as well as the corresponding field
defined in Section 2 of draft-ietf-lsr-ospfv3-srv6-extensions-08.” (And maybe
“and Section 3.1 of draft-ietf-idr-bgpls-srv6-ext-12”?). It might be easier to
drop that change into the IS-IS draft now, before it exits RFC-EDITOR state (if
agreed of course) but we could also do it by patching the registry text in the
OSPFv3 (and BGP-LS?) draft’s IANA section.
Also, a minor point: draft-ietf-lsr-isis-srv6-extensions-19 uses inconsistent
hyphenation for the protocol name — “ISIS” or “IS-IS”. My own preference is
“IS-IS” as both more accurate and not as subject to conflation with other uses
of “Isis”, but anyway please pick one and stick with it? I guess the RFC Editor
will take care of this, but I apologize for not catching it during IESG review.
I see one occurrence of "ISIS" in the latest version of the draft, I
will ask editors to fix that.
(This also leads me to wonder why we even put this registry, that’s shared by
two (three?) protocols, under the IS-IS TLV Codepoints registry instead of
under Interior Gateway Protocol (IGP) Parameters, but given the publication
stage we’re at it may not be worth trying to change that.)
no, the flags are kept independent in each protocol.
thanks,
Peter
Thanks,
—John
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
