On 11/10/2013 11:48 PM, A. Przygienda wrote: > On 11/10/2013 08:12 PM, David Lamparter wrote: >> On Sun, Nov 10, 2013 at 12:55:00PM +0100, A. Przygienda wrote: >>> Thinking further, maybe in the type of TLV encoding it would be good to >>> think about having a 'mandatory/transitory/optional' bit in terms of use >>> by routers (kind of ripping off the BGP'ish and other TLV encodings). >>> Just food for thought here when starting to think about e.g. aggregation >>> of TLVs over prefixes and so on. >> I suggested that a while ago, and in the end it was dismantled because >> there was no real use case that didn't fall apart. If you can come up >> with a good design and something close to a realistic scenario where >> this is used... >> >> > > Hey David, well, searched the archives & found it. Remember even > having read it & actually seems > I commented on it from a different angle. It was more of > the 'ignore/strong unreachable' type & that's why my brain slipped the > connection. >
so, talking to myself (happens often) after having slept & thought about the issue more. A radically more advanced design would be to include in the E-TLV an 'endless' options bitmask which is a mandatory TLV. Think somethink like TLV-007 ;-) Length I support TLV 55,sub-TLV 45,46 I support TLV 57,sub-TLV 47,49 Think a amalgam of router options mask & optional-router-cap put together into a clean protocol design. Ideally, that would be stuck on the router LSA & TLV space be unified for all ext-LSA types (and each sub-TLV space be independent of the main TLV space or think about sub-TLV 7 in TLV 5 as TLV Type 5.7) That would allow for a mixed topology without problems, i.e. in case of 'I-can-only-transition-traffic-on-mondays' the router that does not support the TLV would be left out of computation on sunday by ALL routers that understand the TLV (since it could decide to forward to the guy that can only transition on sundays). They see his TLV-007 and decide he's too dumb to participate. Lack of TLV-007 would indicate simply an old-style router (but then, it wouldn't even have ext-lsas). You would still need a mandatory (and possibly transitory for summaries 3->5 conversions) bit on each TLV since the router not understanding the 'only-on-sundays' mandatory TLV would not compute any routes through a router advertising such TLVs (and ignore prefixes that have not-understood-mandatories) and so on. again, this all only makes real sense if ext-lsa draft is supposed to move OSPF towards a TLV-oriented packet encoding longer term. --- tony
<<attachment: prz.vcf>>
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
