Les,
Responses inline [RON]......
Ron
[rb] I will add some text here. For generality, we accept all of the neighbor
sub-TLVs, however, they are not necessarily semantically significant. This
makes copying the previous adjacency legal. The MP flag should be "Y".
[rb] A sleeping adjacency is not guaranteed to be valid. The neighbor may have
crashed, for example. A two-way check is still advisable.
[LES:] OK - that is sensible. Two-way check should be sleeping-adjacency to
neighbor sleeping adjacency - not sleeping adjacency to adjacency.
And some expected transition time should be allowed since the two neighbors may
not transition at the same moment.
Which raises another question: If one side of the adjacency goes into sleep
mode - but the other does not - then the two way check will fail.
Which means this only works when both sides of the adjacency are put to sleep -
although power savings are still achieved when only one node goes to sleep.
Perhaps this deserves some discussion?
[RON] Yes, the two-way check will be sleeping-adjacency to neighbor sleeping
adjacency - not sleeping adjacency to adjacency. If the check fails, we will
try again.
[rb] A sleeping adjacency and a non-sleeping adjacency for the same adjacency
should not be advertised simultaneously.
[LES:] Agreed. Some text to clarify how this should be handled would be helpful.
Do you prefer the sleeping adjacency or the non-sleeping adjacency? Or ignore
both?
Which relates to the comment I made for the preceding point.
[RON] It is possible that the sleeping and non-sleeping adjacencies will be
advertised simultaneously, but this will be a transient situation, during
flooding. When this is detected, the non-sleeping adjacency will be ignored.
Section 3.3
Defines a Power Group Member sub-TLV - and allows multiple such TLVs to account
for LAGs. But in the absence of information identifying which LAG member is
associated with which power group, it seems difficult to use this at Layer 3
interface level in other than an all or nothing manner - which suggests a
single sub-TLV with a list of Power Group Identifiers is more appropriate.
Power Group Identifiers advertised in TLV 25 (L2 bundle members) naturally
associate the bundle member with the Power Group. Which suggests that the Power
Group advertised at Layer 3 would be the parent of all the Layer 2 member power
groups - and that would be expressed in the Power Group TLV (Section 3.1).
[rb] I will add some text. The purpose of this TLV is not to advertise the
mapping between a LAG and its members. To do so would break the Layer 3
abstraction. The purpose of this TLV is to advertise the mapping between a
Layer 3 interface and the Power Group(s) that support it. If all of the Layer 3
interfaces that a Power Group supports are asleep, the Power Group can also be
put to sleep.
[LES:] OK - rereading the section I sort of get that. But clarification would
help.
If you make the change you say you will do in Section 3.1, I think you could
also advertise many power groups in this sub-TLV as well (rather than many
sub-TLVs)?
[RON] I will add some text around this. Also, we will modify this sub-TLV so
that it can advertise multiple power groups.
[rb] This TLV has nothing to do with putting individual members of a LAG to
sleep
Section 3.3.3
Defines a new Unidirectional Sleeping Bandwidth sub-TLV.
I would assume that this sub-TLV should be ignored if sent in a non-sleeping
Neighbor TLV advertisement?? (Text does not say)
Which is related to the earlier discussion about the Sleeping Adjacencies TLV
as to what link attribute information is actually required when advertising a
sleeping adjacency.
And given that a link cannot be "partially asleep", why wouldn't the bandwidth
sub-TLVs defined in RFC 8570 which indicate how much bandwidth is utilized be
sufficient to indicate "sleeping bandwith" when advertised in a sleeping
adjacency TLV.
[RB] The Unidirectional Sleeping Bandwidth TLV is useful for LAGs only. It
tells us how much sleeping bandwidth is available on the LAG (but not how many
or which members are asleep). RFC 8570 does not tell us anything about sleeping
bandwidth on a LAG.
[LES:] OK - so this meant to appear in neighbor TLVs - not sleeping neighbor
TLVs.
[RON] This is true. I will add text.
References
The reference section is missing many needed entries.
[rb] Which? I would be glad to add them.
[LES:] This is an editorial comment - and as such may get addressed naturally
in later versions. But any codepoint you reference would seem to require a
reference to the RFC that defines it.
"Link Attribute Sub-TLV (19)" is mentioned in Section 3.3.4 and therefore
requires a reference to RFC5029.
I was thinking you had references to the various neighbor TLVs - but currently
you don't other than in the IANA section.
If that changes as a result of your edits, then additional references may be
required.
[RON] I can do this
You may also need some explanation of what sub-TLVs are allowed in the new
Sleeping Adjacency TLV. Not sure how IANA will view this since the new TLV is
currently simply a container for the existing neighbor TLVs.
And your responses above suggest that you are not restricting what sub-TLVs may
be in the contained Neighbor TLVs - but you might want a discussion of which
ones are "significant" and which ones are not.
This gets into nitty-gritty details which might impact interoperability. I
respect the fact that it may a bit early for this level of specification - but
probably will be needed eventually.
[RON] I can add this, too
Les
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
