Les,
> [LES:] I do not object to the Generic-Metric TLV (I believe I stated that at > the beginning). I might not have chosen to do it that way myself - but I am > OK with it. > But one of the consequences of this choice is that not all metric-types can > be advertised in this new format. > This means that for each metric type in the IGP Metric Types Registry (now > and in the future) we need to state whether the type is encoded in > Generic-Metric sub-TLV or not. Fair enough. I would expect anything in the generic metric to a local matter anyway. Anything that needs a new IGP Metric Type is clearly a global definition. > IGP: This is not encoded in a sub-TLV of any flavor. > TE: There is an existing sub-TLV - so yes - backwards compatibility is an > issue. I see no reason to reinvent the advertisement for this. > Delay: The value used for this metric is derived from Min/Max Unidirectional > Link Delay sub-TLV(34). This encoding does not fit in the Generic-Metric > format and even if it did it would be redundant and not backwards compatible. Of course, no objection. > For new metric-types: > > Whether they can be advertised in Generic-Metric is dependent upon the value > associated with the advertisement. > Since you say you do NOT want to define a restriction on new metric-types to > always match Generic-Metric format, that means for each new type we will also > need to indicate whether it is advertised in Generic-Metric or not. > > I hope this is not controversial - just a detail that needs to be attended to > in the draft. Not controversial. Please propose wording that would make you comfortable. Tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
