Hi authors,
I have some comments below regarding the draft:
1) Section 2: "There is currently only two Flag bits defined." Per -07
only one flag is defined. S flag was deprecated since version -06
(implicit signaling of presence of Sub-TLVs is used via "Sub-TLV Len"
field non-zero value. Text in the beginning of the chapter 2 about flag
S is to be removed as well.
2) Section 3.1: "In order to ensure that an individual TE link is used
as a link of last resort during SPF computation, ..." I guess that you
meant regular link rather than TE link.
3) For the same section: Per my understanding, this section assumes that
overloaded link will always be considered as last-resort link. I.e. it
cannot be excluded from topology (as link with metric 2^24-1), unless
originator of the TLV sets appropriate bit in corresponding Link
Attributes Sub-TLV (RFC 5029) AND receiving ISs support that Sub-TLV. As
alternative it could be done by allowing for originator to specify
reverse metric special value 2^24-1 which would indicate to receivers
that the link is to be excluded from topology completely rather than
used as last resort. If reverse metric value is between 0 - 2^24-2 then
link could be used in path calculation. The same rules for TE metric.
4) For the same section: The draft says that if originator uses narrow
metric-type, it should use value 63 as max-metric. But on receiving
reverse metric with such value receivers have no idea whether this is
"narrow" max-metric or offset 63 for "wide" metric. I.e. the draft
assumes that all ISs use the same type of metric, and using of two
metric types at the same time is not covered. May be it would be
appropriate to define two Reverse Metric TLVs, like IS Neighbors TLV and
Extended IS Reachability TLV. Or to specify new flag to mark type of the
reverse metric.
5) For the same section: It is not clear for me why DIS should use
min(63, (Metric + Reverse Metric)) while composing pseudonode LSP. If
DIS is configured for using "wide" metric-type, it will use Extended IS
Reachability TLVs for describing its neighbors. Moreover, in this case
DIS is not obligated to still insert IS Neighbors TLVs in its Pseudonode
LSP (in addition to Extended IS Reachability TLVs) when it is configured
for "wide-only" mode.
6) For the same section: It is not clear for me why in case when TE
metric offset is not advertised in Reverse Metric TLV, receiving IS must
modify its TE metric by adding IGP reverse metric value. In my mind, it
would be straightforward to use follow rule: if originator doesn't
include TE metric part then it doesn't wish to overload TE link, but
only IGP link. For example, originator advertises Reverse metric TLV as
part of IGP-LDP synchronization procedure (section 3.5). It is not
reason to impact TE properties (metric in this case) of the link. Hence,
originator could advertise Reverse metric TLV without TE metric Sub-TLV,
in order to signal that "TE metric is left intact".
7) Section 3.3: The draft is not clear about handling of TE metric by
DIS. Usually DIS implementations don't insert TE Sub-TLVs into Extended
IS Reachability TLVs in Pseudonode LSP. May be it would be better to add
explicit text that: if DIS receives TE metric Sub-TLV in Reverse Metric
TLV it should update TE Default Metric Sub-TLV value of corresponding
Extended IS Reachability TLV OR insert new one if it was not present there.
Thanks!
30.11.2017 01:47, Naiming Shen (naiming) пишет:
Hi Ketan,
thanks for the support and comments. some clarification inline,
On Nov 28, 2017, at 11:54 PM, Ketan Talaulikar (ketant) <[email protected]>
wrote:
Hello,
I support this draft, however would like the following aspect/scenario
clarified.
Consider the scenario where both the neighbours on a p2p link initiate the reverse metric procedure
(i.e. include the TLV in their hellos concurrently). How are implementations supposed to handle
this? Normally the choice of metric conveyed via this TLV is based on a particular condition (which
need not just be "overload") on the local router which requires the neighbour to use
shift to using the reverse metric supplied. So when both neighbours initiate this process, it would
be good to have the specification provide a deterministic behaviour since the reverse metric values
provided may conflict in certain "non-overload" conditions. If both routers simply accept
the value supplied by their neighbour, it may not achieve the original purpose/design of this
triggering this mechanism?
When you say if both sides initiated this ‘reverse metric’, you implied
there is a timing issue with this procedure in the draft.
The value of this ‘metric offset’ (or whatever will be called) of this TLV,
is just a number. The draft does not say this number is equal to the
configured ‘metric’ value plus the received ‘reverse metrc’ value, that
would be non-deterministic and both sides would keep going up until it’s
overloaded:-)
Each side of IS-IS link decides if it needs to send a ‘reverse metric’ over the
link,
either in link-overloading case, or other cases. It’s a static number, it does
not
depend on the other side sending a ‘reverse metric’ or not. This both sides
sending a ‘reverse-metric’ over a link is equivalent to an operator provisions
new metric (say both plus 10 to the old metric) on both sides of the link at
the same time, there is no non-determinitic thing in this.
thanks.
- Naiming
Following options come to my mind:
a) when this condition is detected, none of the routers actually apply the
reverse metric procedure
b) when this condition is detected, the router with higher/lower system-id
value (or some such tiebreaker) wins and the other withdraws its reverse metric
(until then (a) applies)
c) some mechanism/rule that is based on the value of metric offset specified perhaps
(made harder since the actual metric is not signalled but the offset) which determines
the "winner" so the other withdraws their TLV.
Since the mechanism is not specific to overload conditions (where this is not
an issue), it may be necessary for the specification to clarify this behaviour
to ensure interoperability.
Thanks,
Ketan
-----Original Message-----
From: Isis-wg [mailto:[email protected]] On Behalf Of Christian Hopps
Sent: 16 November 2017 04:13
To: [email protected]
Cc: [email protected]
Subject: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07
The authors have asked for and we are starting a WG Last Call on
https://datatracker.ietf.org/doc/draft-ietf-isis-reverse-metric/
which will last an extended 3 weeks to allow for IETF100.
Thanks,
Chris.
_______________________________________________
Isis-wg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/isis-wg
