Hi Peter, Tony, On Sep 2, 2014, at 3:25 AM, Peter Psenak <[email protected]> wrote:
> Hi Tony, > > please see inline: > > On 9/1/14 23:34 , A. Przygienda wrote: >> Comments: >> >> a) section 1. introduction last line >> >> > the existing LSAs will be replaced _BY_ TLV-based extended LSAs. > > ok, > >> >> b) section 2. >> >> It may be well writing a sentence or two what should happen if an OSPFv2 >> Extended Prefix Opaque LSA changes its flooding scope (i.e. 9-11 >> changes) and what should happen if the same prefix appears in two >> different flooding scopes with different information (ignore prefix in >> both, prefer local scope info ? [i.e. ignore wider scope]). Leaving it >> open may lead to different treatement per router and surprising effects > > as far as the information in the two LSAs are the same, having the prefix in > two LSAs with different flooding scopes is not a problem - happens today with > regular LSAs.) The problem would be if the content of TLVs associated with > the prefix is controversial, in which case it would be a defect on the > originator side. This is another case where the segment routing mapping server requirement makes this more complicated. I think the guidance for the case should be to give preference to the information in the LSA with area flooding scope. > >> >> It may be also helpful to add that if an opaque extended is present but >> the prefix (of the according type) is not in the standard LSAs, such >> information must be disregarded. > > no, that is a valid case. One may want to advertise some extended prefix > attributes without advertising the prefix's reachability. > >> >> c) section 2.1 >> >> > Multiple OSPF Extended Prefix >> > TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA but >> > all prefixes included in a single OSPFv2 Extended Prefix Opaque LSA >> > MUST have the same flooding scope. >> >> may be misleading. Since they are in a opaque, the flooding scope is >> controlled by opaque. If the type-5 vs. type-3 is meant than 'flooding >> scope' must be disassociated between 'opaque flooidng scope' and >> 'route-type flooding scope [as in we don't flood type-1 across ABRs]' ? > > LSA can only have single flooding scope, so all information inside LSA is > limited to that flooding scope. That is what was meant by the above texts. Actually, I had considered removing this statement when I separated the generic protocol extensions from the SR specific draft. > >> >> >> d) >> I think it may be a valid suggestion to implementors that (for every >> version) the according LSA SHOULD be flooded _before_ the opaque LSA >> is flooded (which can be tad tricky [but doable] if the opaque carries a >> bunch of those]). Yes, with reordering of flooding etc. it's not a >> guarantee for anything but a good practice to give the protocol a chance >> to distribute the referent (LSA) before distributing any references >> (opaques) and additionally, will make sure that LSAs which are far more >> important normally get out the box before opaques. > > as I said, not flooding regular LSA, only extended LSA is a valid case. In any case, an application using extended attributes will need to be triggered by the extended prefix/link attribute LSAs. The advertising router may originate one or both of them independently. I will try to capture this disjointness in a paragraph. Thanks, Acee > > thanks, > Peter >> >> >> --- tony >> >> >> On 08/13/2014 06:12 AM, Acee Lindem (acee) wrote: >>> Hi, >>> >>> This new draft describes the generic prefix/link attribute opaque LSAs >>> that were previously included in the OSPFv2 Segment Routing draft. The >>> opaque LSAs described in this draft can be used by other OSPF WG candidate >>> drafts. There are already two implementations of the draft as part of >>> segment routing interoperability testing. Please read and comment. >>> Thanks, >>> Acee >>> >> >> >> >> _______________________________________________ >> OSPF mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ospf >> > > _______________________________________________ > OSPF mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
