Hi Tom,
Thank you very much for your comments. Please see inline...
Best Regards,
Ran
Original
RFrom: tompetch <[email protected]>
To: Acee Lindem <[email protected]>;lsr <[email protected]>;
Cc: [email protected]
<[email protected]>;
Date: 2024年12月23日 19:40
Subject: [Lsr] Re: IPR Call for WG Last Call on "Prefix Flag Extension for
OSPFv2 and OSPFv3" - draft-ietf-lsr-ospf-prefix-extended-flags-03
Suive
From: tom petch <[email protected]>
Sent: 22 December 2024 17:24
From: Acee Lindem <[email protected]>
Sent: 20 December 2024 18:26
This email begins a 2 week WG Last Call for the following draft: "Prefix Flag
Extension for OSPFv2 and OSPFv3" - draft-ietf-lsr-ospf-prefix-extended-flags-03
Please review the document and indicate your support or objections by January
11th, 2025. The extra week is to allow for the holidays.
<tp>First impression - needs tidying up'there are not many undefined bits'How
many? please work it out for me allowing for I-D work in progress and the
like.Perhaps, 'At the time of writing, there are ...' better still, identify
the bits
Ran： Upadated to：and for OSPFv2, at the time of writing, only 4 bits remain
undefined in the OSPFv2 Extended Prefix TLV.
Please check.
/flield/ field /
'that are undefined as shown in Table 1.'well, no; undefined does not figure in
Table 1 (but it should IMHO)
Ran： Upadated to：For OSPFv2, as defined in RFC7684, the length of the Flag
field is 8 bits, and it has been defined the below flags as shown in Table 1.
Please check.
If no flags are defined is it valid to send the Sub-TLV?
Ran：As an originating node, such Sub-tlv should not be sent. As an intermediate
node, Sub-tlv should be transparently transmitted.
'An implementation that
does not understand or support the Prefix Attribute Flags Sub-TLV MUST
ignore the TLV.'which is fine if that behaviour is already in place. What is
the expected behaviour for Sub-TLV that is not recognised? where is it defined?
Ran：Upadated to：An implementation that does not recognize the Prefix Attribute
Flags Sub-TLV MUST ignore the sub-TLV. Please check.
And 'ignore the TLV' or 'ignore the Sub-TLV'?
Ran: 'ignore the Sub-TLV'.
<tp2>
'capabilities,by
There is a character in there after the comma but it does not seem to be
behaving the way I expect a space to
| TBD | U | [I-D.ietf-lsr-igp-ureach-prefix-announce] |
** should be Normative IMHO
Ran: [I-D.ietf-lsr-igp-ureach-prefix-announce] is only used for background.
The extension of draft-ietf-ospf-prefix -extended flags doesn't depend on
draft-lsr-igp-ureach-prefix-announce. In addition,
ietf-lsr-igp-ureach-prefix-announce will be removed in next version becauese
its extension is extended in OSPFv2 Prefix Attribute Flags(defined in this
draft ) not in the OSPFv2 Extended Prefix TLV(defined in RFC7684).
' This document creates the variable length Prefix Attribute Flags Sub-
TLVs for OSPFv2 and OSPFv3 respectively. '
Not really - it just creates the one for both so 'respectively ' confuses me
Ran: It is two sub-TLVs, not one. Although the format is the same.
' It MUST be a multiple of 4 octets.'
and if not? ignore the excess? ignore the sub-TLV?
Ran: If not, the sub-TLV is invalid and the sub-TLV is ignored.
what if the TLV appears twice, once valid and once invalid because someone
realised they had made a mistake but did not clean up properly?
Ran: Only the first one is valid, the others will be ignored
Ditto for OSPFv3.
'Currently, no bits are defined in this document.
Unassigned bits MUST be set to zero on transmission and MUST be
ignored on receipt.'
What is the difference between 'defined' and '(un)assigned'?
Ran:The same meaning, the next version will uniformly change the allocation to
undefined.
3,
'Flags that an implementation is
not supporting MUST be set to zero on transmission'
And if no flags are supported, is the Sub-TLV omitted or sent with zeros?
Ran: Upadated to：Flags and Sub-TLV that an implementation are not supporting
MUST be transmitted transparently.
'it currently supports or understands, '
What is the difference between supports and understands? 'understands' seems
redundant
Ran: Yes. 'understands' can deleted.
'as if they are set to 0'
'it MUST act as if
the bits beyond the length were not set.'
Is there a difference between not set and set to zero? I do not see one
Ran: There is no difference between unset and set to zero. The next version
will be unified: set to 0.
More generally, if a future implementation supports e.g five flags but the
transmitting implemenation only supports three, can the receiver tell? I think
not which means that the zero state of a flag must cause no action, no change.
Seems quite a burden, a pitfall that others may fall into in future.
Ran: A node that only supports three flags receives five flags. This node only
processes three of the flags, ignores the other two, and transparently
transmits the five flags to other nodes.
Tom Petch
Thanks,
Acee
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
