Hi Tony, 

Thanks for the review. 

> On Feb 27, 2024, at 04:51, Tony Przygienda <[email protected]> wrote:
> 
> Reading the draft quickly, here's bunch of observations
> 
> "
> 
>    An OSPF router supporting this specification MUST be able to
>    advertise and interpret at least one 32-bit tag for all type of
>    prefixes.  An OSPF router supporting this specification MAY be able
>    to advertise and propagate multiple 32-bit tags.  The maximum tags
>    that an implementation supports is a local matter depending upon
>    supported applications using prefix tags.
> "
> 
> Since different implementations may support different amount of tags I see 
> that the draft says 
> 
> "
> When propagating multiple tags, the order
>    of the the tags SHOULD be preserved.
> 
> "
> 
> this is IMO not good enough in case where two nodes advertise same prefix 
> with multiple tags, possibly differing or in different order. Some kind of 
> ordering is necessary then as well AFAIS.

I guess I don’t see the problem. A policy would look for a specific tag and 
take a specific action. 

Note that for IS-IS tags so require ordering, see section 4 of  
https://datatracker.ietf.org/doc/rfc5130/.
I could possibly appropriate some of this text as it applies to OSPF. 




> 
> 
> "
>    This sub-TLV will carry one or more 32-bit unsigned integer values
>    that will be used as administrative tags.
> "
> 
> IMO behavior when none are carried nees to be specified if this is mandated. 
> is that a MUST in fact? 

 The sub-TLV is optional so if it isn’t specified than there are no tags to 
match. What am I missing here? 


> 
> 
> Moreover we already have a tag in OSPFv2 on type-5 and type-7 and opaque can 
> advertise more tags. How do those interact ?


I have this text in section 4 to provide backward compatibility:

   When tags are advertised for AS External or NSSA LSA prefixes, the
   existing tag in the OSPFv2 and OSPFv3 AS-External-LSA and NSSA-LSA
   encodings SHOULD be utilized for the first tag.  This will facilitate
   backward compatibility with implementations that do not support this
   specification.

Thanks,
Acee



> 
> that's it for the first 
> 
> thanks 
> 
> -- tony 
> 
> _______________________________________________
> Lsr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to