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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Tony –

Thjanx for the quick comments.

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…?



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. ☺ )



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?



   Les



just perfunctory read between other stuff ...



thanks



-- tony







On Wed, Oct 7, 2015 at 9:04 PM, Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>> wrote:
Folks -

We have just submitted a bis draft for RFC 4971 to define how to use TLV 242 on a router which supports only IPv6 (has no IPv4 addresses).

The draft is identical to the original RFC except for:

1)New text at the beginning of Section 3 defining how to use the TLV when no IPv4 Router ID is present

2)References have been updated

Please let us know of any questions or comments.

   Les (on behalf of Stefano and Mach)

-----Original Message-----
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Wednesday, October 07, 2015 8:59 PM
To: Mach Chen; Stefano Previdi (sprevidi); Les Ginsberg (ginsberg); Stefano Previdi (sprevidi); Les Ginsberg (ginsberg); Mach Chen (Guoyi)
Subject: New Version Notification for draft-ginsberg-isis-rfc4971bis-00.txt


A new version of I-D, draft-ginsberg-isis-rfc4971bis-00.txt
has been successfully submitted by Les Ginsberg and posted to the IETF repository.

Name:           draft-ginsberg-isis-rfc4971bis
Revision:       00
Title:          IS-IS Extensions for Advertising Router Info
Document date:  2015-10-07
Group:          Individual Submission
Pages:          9
URL:            https://www.ietf.org/internet-drafts/draft-ginsberg-isis-rfc4971bis-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ginsberg-isis-rfc4971bis/
Htmlized:       https://tools.ietf.org/html/draft-ginsberg-isis-rfc4971bis-00


Abstract:
   This document defines a new optional Intermediate System to
   Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple
   sub-TLVs, which allows a router to announce its capabilities within
   an IS-IS level or the entire routing domain.





Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
Isis-wg mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/isis-wg



--
We’ve heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.
—Robert Wilensky