Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt

From: "A. Przygienda" <[email-masked]>
Date: Mon, 01 Sep 2014 14:34:54 -0700

Comments:

a)   section 1. introduction last line

> the existing LSAs will be replaced _BY_ TLV-based extended LSAs.

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

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.

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]'  ?

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.

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

---

From: Peter Psenak <[email-masked]>
Date: Tue, 02 Sep 2014 09:25:38 +0200

Hi Tony,

please see inline:

>  > the existing LSAs will be replaced _BY_ TLV-based extended LSAs.

ok,

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

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

> '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.

> important normally get out the box before opaques.

as I said, not flooding regular LSA, only extended LSA is a valid case.

thanks,
Peter
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 2 Sep 2014 10:23:42 +0200

hi tony,

requiring send-side ordering is certainly intended well,
but that in itself does not guarantee ordered delivery
at the receiving end :-/.

IOW in case you have an application that needs both
the 1) prefix-LSA and the 2) extended-prefix-LSA you need
to have the logic that checks presence of 1)
at the receiving end anyway.

rather than doing things on the send-side let me suggest
to check if you have got your act together during
route-computation time. (this is a bit akin to
IS-IS fragment zero handling - ala - if frag zero
is not present then all non-zero
frag content has to be disregarded).

HTH,

/hannes

On Mon, Sep 01, 2014 at 02:34:54PM -0700, A. Przygienda wrote:
[ ... ]
|    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.
| 
|    --- tony

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 2 Sep 2014 13:37:40 +0000

Hi Peter, Tony, 

On Sep 2, 2014, at 3:25 AM, Peter Psenak <[email-masked]> wrote:

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

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

> 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

---

From: "A. Przygienda" <[email-masked]>
Date: Wed, 03 Sep 2014 08:40:59 -0700

> hi tony,

Fuehrt' Di' Hannes ;-)
> at the receiving end :-/.

I think I pointed that out already below. full ack.
> frag content has to be disregarded).

That is required anyway, the ordering was meant as suggestion for
implementors but given what Peter/Acee write (extented can be sent
without the normal LSA, this makes no sense apparently).

--- tony

---

From: "A. Przygienda" <[email-masked]>
Date: Wed, 03 Sep 2014 09:13:11 -0700

Hey Acee,
> 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 w…
agree.  preferring area (or in extreme case link scope ?) is simplest
resolution of the issue. Agree with Acee here. 

It's also wise to add 'if the same extended prefix TLV (i.e. for same
prefix) is seen twice in same opaque LSA only use the first and force
people to put all sub-tlvs into a single tlv.
>> no, that is a valid case. One may want to advertise some extended prefix attributes without advertising the prefix's reachability.
Here I think the draft may benefit from some clearer writing. Even an
experienced OSPF reader is lead to assume that original LSA must be
present to use the extended.

"OSPFv2 requires functional extension beyond what can readily be done
with the fixed-format Link State Advertisements (LSAs) as described
in RFC 2328 [OSPFV2]. This document defines OSPF opaque LSAs based
on Type-Length-Value (TLV) tuples that can be used to associate
additional attributes with advertised prefixes or links."

That's strongly suggestive of "you advertise normal LSA and then you use
opaque to 'extend' it" . Extended extends and is not independent from
original stuff in normal use of English idiom.

On top, if you start to advertise opaques & people start to compute
reachability or distance based on opaques (unless you specificall state
in this draft that it _cannot_ be used for that purpose, i.e. opaque
influences reachability or computed metric)  and you can have routers in
the area that do not support opaques,  an additional text is needed
saying  "never compute through routers without opaques using information
in opaques that influences reachability or metrics". Actually, it's
worse since if a router without opaques forwards through a router
advertising opaques influencing metrics (for sake or simplicity), you
cannot start using opaques to keep on forwarding.  In case that all
doesn't parse, I can do a simple looping example.

> Actually, I had considered removing this statement when I separated the generic protocol extensions from the SR specific draft. 

OK, I still don't understand 'WHICH flooding scope', the  type-3 vs.
type-5 one or the 'opaque flodding scope one'.  I think you mean 'all
prefixes in the same opaque must have the same OSPF-route-type
[0+unevens]'  but the text is really hard to parse here. 

Acee, you mean remove the restriction ?  I see how some implementations
may benefit from cramming all type-3 into the same opaque but I would
also suggest to not restrict this and remove the text.
> 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.…

yes, and again, I think 'extended' is an ill chosen name maybe if that's
the intention of the draft.

BTW, what is the plan if all the TLVs blow out the MTU of the opaque ? 
I'm missing something ?   RFC5250 is not describing how the instance
(they call it Opaque ID) is supposed to be generated (it references
appendix A referencing section 7 which has nothing in it about this). 
I'm divining the instance allows to have multiple opaques of the same
type which leads to bunch interesting discussions
     * what happens when the MTU gets blown & TLVs are shifted into next
'fragment' in ISIS speak [with all the restrictions how the TLVs can
migrate between fragments, ISIS guys suffered this one [as did PNNI] @
length & will surely lend a helping hand in such a case].
     * what happens if the same extended prefix TLV shows up twice in
two different opaques of same type ?  You use the one that is in lower
opaque ID ?

All nit-picking based on ample scar tissue with TLV based protocols in
real deployments.

thanks

--- tony

---

From: Peter Psenak <[email-masked]>
Date: Thu, 04 Sep 2014 09:24:23 +0200

Hi Tony,

please see inline:

> people to put all sub-tlvs into a single tlv.

it's kind of obvious, but we can add a text to be sure.

> original stuff in normal use of English idiom.

because existing LSA are not extensible, any additional link/prefix 
attributes must be advertised in a separate LSAs. We called it 
"extended", but it does not mean that existence of the extended LSA 
require existence of the base LSA. I had a text in the original SR draft 
around that, we can add it here too.

> doesn't parse, I can do a simple looping example.

we are not advertising any metrics in the extended LSAs, so I do not see 
why we would have to deal with that case here. If one day someone wants 
to do that, then it would have to be covered in a separate draft and we 
would deal with it at that time.

> also suggest to not restrict this and remove the text.

the restriction can not be removed. All the Extended Prefix TLVs that 
you put in a singe Extended Prefix LSA will only use a flooding scope of 
the Extended LSA itself.

> BTW, what is the plan if all the TLVs blow out the MTU of the opaque ?

you can generate many Extended Prefix or Extended Link LSAs, so there is 
no issue.

>       * what happens when the MTU gets blown & TLVs are shifted into
> next 'fragment' in ISIS speak [with all the restrictions how the TLVs
> can migrate between fragments, ISIS guys suffered this one [as did PNNI]
> @ length & will surely lend a helping hand in such a case].

TLVs can come and go and move from one Extended Opaque LSA to the other. 
Implementation needs to track these changes and deal with them.

> two different opaques of same type ?  You use the one that is in lower

I would call it a bug on the originator side.

thanks,
Peter

---

From: "A. Przygienda" <[email-masked]>
Date: Thu, 04 Sep 2014 12:02:54 -0700

> please see inline:

Hey Peter, same

> it's kind of obvious, but we can add a text to be sure.

As I see it, the purpose of an RFC is to assure interoperability. If
there are two
interpretations available of the same packet that will make two
solutions not interoperable, 
the standard has to mandate the correct one.

> require existence of the base LSA. I had a text in the original SR
> draft around that, we can add it here too.

yepp, once it spelled out, it's obvious but the first conclusion one
jumps to is that they are inter-dependent otherwise.

>> .,..
> we are not advertising any metrics in the extended LSAs, so I do not
> see why we would have to deal with that case here. If one day someone
> wants to do that, then it would have to be covered in a separate draft
> and we would deal with it at that time.

agreed here. you're correct. That would be overspecification in this draft

> you put in a singe Extended Prefix LSA will only use a flooding scope
> of the Extended LSA itself.

I still think it's not clear what the original paragraph means.

> you can generate many Extended Prefix or Extended Link LSAs, so there
> is no issue.

ack

> TLVs can come and go and move from one Extended Opaque LSA to the
> other. Implementation needs to track these changes and deal with them.

I would let the ISIS guys chime in here. They have tons experience with
TLVs sliding fragments and what kind of implementation/operation pain
that can cause.

> I would call it a bug on the originator side.

yes, but still, the draft should mandate what the desired behavior is @
this point in time otherwise some will use the lower ID, some higher and
some none of the above & the implementations will not interop ?

--- tony

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 5 Sep 2014 09:10:38 +0200

On Thu, Sep 04, 2014 at 09:24:23AM +0200, Peter Psenak wrote:
| Hi Tony,
| 
| please see inline:
| 
| On 9/3/14 18:13 , A. Przygienda wrote:
| >Hey Acee,
| >>>>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.
| >agree.  preferring area (or in extreme case link scope ?) is simplest
| >resolution of the issue. Agree with Acee here.
| >
| >It's also wise to add 'if the same extended prefix TLV (i.e. for same
| >prefix) is seen twice in same opaque LSA only use the first and force
| >people to put all sub-tlvs into a single tlv.
| 
| it's kind of obvious, but we can add a text to be sure.
  ^^^^^^^^^^^^^^^^^^^^

only for the educated eye :-)

---

From: Peter Psenak <[email-masked]>
Date: Fri, 05 Sep 2014 10:34:04 +0200

Hi Tony,

please see inline:

> the standard has to mandate the correct one.

ok, we will add a text to make it clear.

> jumps to is that they are inter-dependent otherwise.

ok, we will add a text to clarify.

> I still think it's not clear what the original paragraph means.

prefixes can have different flooding scope. Today intra-area and 
inter-area prefixes have area flooding scope and external prefixes have 
domain wide flooding scope. You can not mix prefixes of different 
flooding scope in a single Extended Prefix LSA, because Extended Prefix 
LSA can only have a single flooding scope.

> some none of the above & the implementations will not interop ?

ok, we will add a tiebreaker there.

thanks,
Peter
> .

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 5 Sep 2014 12:37:15 +0000

Hi Tony, Peter, 

I plan to update the draft next week and address some of these
clarifications.

Thanks,
Acee

---

From: "A. Przygienda" <[email-masked]>
Date: Sat, 06 Sep 2014 07:47:01 -0700

ack
ack
> inter-area prefixes have area flooding scope and external prefixes
> have domain wide flooding scope. You can not mix prefixes of different
> flooding scope in a single Extended Prefix LSA, because Extended
> Prefix LSA can only have a single flooding scope.
>
yes, this is now clearly spelled out.  I suggest adding that to the
draft with a MUST NOT and addition that if they are, the behavior of the
protocol is unspecified/incorrect.
ack

All my issues have been adressed then except concerns about the 'any
prefix in any opaque'. Let me explain.

Let's say I have an extended prefix X providing service X'.  The prefix
is advertised in opaque O_1.
If I remove it from O_1 and move it to O_2 (due to running out of space,
weak implemenation and so on)
but O_1 is flooded out there before people pick up O_2, service X' will
be interrupted.

This sounds not too bad but imagine you advertise 50 new prefixes that
slide 50 prefixes from the original
O_1.  Same for deletions. Now your protocol becomes quite fragile (if
interested further,
look @ ISIS treatement of that problem)

Waiting for new version

-- -tony

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 6 Sep 2014 18:05:37 +0000

>protocol is unspecified/incorrect.

I guess I still see this is a tautology since the LSA type defines the
flooding scope that need not be in the draft. If you advertise a prefix in
an LSA with a given flooding scope, then by definition, the prefix is
advertised at the flooding scope of that LSA. Let me try and reword this
so that it reflects the required flooding scope for the prefix.

>look @ ISIS treatement of that problem)

OSPFv3 has this situation today as well for Router-LSA links - in this
case, implementations will reoriginate all the changed Router-LSAs at
³nearly" the same time and, more often than not, the changed LSAs are
processed by other OSPFv3 Routers in the same SPF cycle. This is an
implementation issue and the protocol itself need not try and guarantee
seamless transition. However, I will think about how to add some guidance.
One of the many advantages of OSPF over ISIS is that OSPF allows for
intelligent grouping of information in separate LSAs to avoid the inherent
problems with regeneration of LSPs.

Thanks,
Acee

---

From: "A. Przygienda" <[email-masked]>
Date: Sat, 06 Sep 2014 11:57:01 -0700

> so that it reflects the required flooding scope for the prefix.

yes, you can see it like that, i.e. if the  flodding scopes are strictly
linked to each other, then the
text should be

    advertise  LSA-1,.. @ area scope
    advertise LSA-5,.. @ domain scope

Any LSA-1 in domain scope MUST be disregarded & so on.

That makes it tight, clean and easy to understand. I'm with you here.

> problems with regeneration of LSPs.

Yes, I agree with the grouping but the same type of information can
still blow out an opaque (as here) and then
some, as you say, implementation guidance is, albeit not strictly
protocol specification, beneficial to have
higher quality implementations out there (which for OSPF, with lots of
people @ different clue level
implementing it, is probably more important even than for ISIS).

Yes, it's largely matter of judgement so I'm just lighting out the
complete landscape to get a draft of max quality out & don't feel
strongly either way about this one.

--- tony