Re: [Isis-wg] FW: New Version Notification for draft-ginsberg-isis-rfc4971bis-00.txt

[Tony Przygienda <[e-mail]>]

>
>
>
>
> *From:* Tony Przygienda [mailto:[e-mail]]
> *Sent:* Wednesday, October 07, 2015 9:44 PM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* ISIS-WG; Stefano Previdi (sprevidi)
> *Subject:* Re: [Isis-wg] FW: New Version Notification for
> draft-ginsberg-isis-rfc4971bis-00.txt
>
>
>
> two observations off the cuff:
>
> a)
>
>
>
> " The Router ID SHOULD be identical to the value advertised in the
>
>    Traffic Engineering Router ID TLV [RFC5305].  If no Traffic
>
>    Engineering Router ID is assigned the Router ID SHOULD be identical
>
>    to an IP Interface Address [RFC1195] advertised by the originating
>
>    IS.  If the originating node does not support IPv4, then the reserved
>
>    value 0.0.0.0 MUST be used in the Router ID field and the IPv6 TE
>
>    Router ID sub-TLV [RFC5316] MUST be present in the TLV.  Router
>
>    CAPABILITY TLVs which have a Router ID of 0.0.0.0 and do NOT have the
>
>    IPv6 TE Router ID sub-TLV present MUST be ignored."
>
>
>
> OK, so won't we end up with different understanding of what a router ID is between routers supporting this CAP sub-TLV and routers that don't in case the router ID in the new sub-TLV and the normal (5305) do not agree  unless you specify that 5305 takes preference _or_ say that they MUST (and not SHOULD) match ?
>
> Interesting conversation as to what today's routers do if you give them 0.0.0.0 for IPv4 TE ID.
>
>
>
> *[Les:] The reason SHOULD is used is because a strict interpretation of the existing RFC allows the router ID to be different than TLV 134 (RFC 5305) simply because the RFC does not say that they MUST be the same – in fact it doesn’t say anything at all about the relationship. I don’t know why any implementation would use something other than what they advertise in TLV 134 (assuming it is advertised) – but it did not seem to make sense to have the bis version suddenly make existing implementations non-conformant. I would hope all implementations are already doing this, but who knows…?*
>
> OK, hmm, so we leave a hole because we have a hole is not an impressive
reasoning but since no'one bumped over the hole it seems it's small ;-)
 About as much I have to say about it.


>
>
> b) " In order for Router CAPABILITY TLVs with domain-wide scope originated
>
>    by L1 Routers to be flooded across the entire domain, at least one
>
>    L1/L2 Router in every area of the domain MUST support the Router
>
>    CAPABILITY TLV."
>
>
>
> that seems to indicate that a router CAN originate a domain-wide scope even though it doesn't a L1/L2 in the domain supporting the CAP TLV but it can be read as "though SHALL NOT".
>
>
>
> *[Les:] An L1 router can generate a Router Capability TLV with domain-wide scope – but clearly unless there exists an L2 router in the area the domain-wide flooding will never occur. That’s the point the existing text is trying to make (just in case you didn’t already know that. **J** )*
>
>
>
> Side question: what is the indication that a router supports CAP TLV ? Does it have to advertise an empty one even if it has nothing to tell to indicate that "I support CAP TLV"
>
>
>
> *[Les:] There is no indication of support – and no need to generate a CAP TLV unless you actually have something to advertise.*
>
> *Why do you think such a thing would be needed? *
>
>
>
> Would be only needed if such a "SHALL NOT" would be in place, i.e. someone
can advertise certain capability only if other routers have it but since I
agree the most natural interpretation of the text is "you can do it, it
just won't flood domain-wide", no need I see.

Like I said, I had the deja vu while writing my comments [which were minor
anyway], had to re-read to remember the details (I'm soaking in many more
than a single protocol or layer or technology these days, my brain starts
as self-defense swap things out quickly ;-) , I agree that no further
action is needed.

thanks for amusing me ;-)

-- tony