Hi Tom，
Thank you very much for your comments. Sure. The behavior will be added in the
next version.
Best Regards,
Ran
Original
From: tompetch <[email protected]>
To: 陈然00080434;
Cc: [email protected] <[email protected]>;[email protected]
<[email protected]>;[email protected]
<[email protected]>;
Date: 2024年12月30日 19:11
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
Just one point which I have copied to the front
________________________________________
From: [email protected] <[email protected]>
Sent: 24 December 2024 09:32
Hi Tom,
Thank you very much for your comments. Please see inline...
<tp2>
'More generally, if a future implementation supports e.g five flags but the
transmitting implementation 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.
<tp2>
I think that that behaviour needs spelling out explicitly.
You are saying that an implementation must act on things it has no knowledge
of, flags that as far as it is concerned have not been defined. I think that
you need to say something like
'The flag field MUST be copied in its entirety to the outgoing message even
when the implementation does not understand all the flags.'
(or something along those lines).
Tom Petch
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]_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
