Subject: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02

From: "Martin, Christian" <[email-masked]>
Date: Thu, 11 Apr 2002 15:55:11 -0400

Tony,  I think we are clear.  A few more questions for the group, inline.

>Christian,
>
>Inbetween my ramblings, a little unordered
>
>>
>> >
>> > why don't you add the multi-topology to the list. It's 
>aligned with 
>> > the TE draft. You can mention the prefix color already contained 
>> > within as an orthogonal issue.
>>
>> Do you mean the draft as a reference?
>
>I actually thought you would list MT TLVs as being able to 
>contain those sub-TLVs as you list the TLVs of the TE draft 
>for example.

Got it now - I am adding the subTLVs to TLV 235.  

>> Also, should we reserve tag space for future use, a la communities? 
>> 0xFF000000 to 0xFFFFFFFF?  Same for Extcomms?  Further, are we being 
>> agnostic to the contents of a 64-bit tag (and a 32 bit tag), 
>or are we 
>> saying that the 64 bit tag is to carry ext-communities?  In these 
>> cases, the ordering is important, IMO.
>
>I had the suspicion that's why I brought the issue up. That's 
>why I would like to see text explaining whether you guys make 
>assumptions about ordering, what duplicate valuies within same 
>sub-TLV mean and whether you can have and what the semantics 
>of multiple instances of a sub-TLV mean. And I think best is 
>to not to make the draft normalize anything in terms of those 
>things and leave it over to the application and maybe add as 
>example describe your scenario where the application (ext. 
>comm-tag translation) assumes ordering.

As I see it, it is similar to a community string, rather than an AS PATH.
There is an implied ordering, and the ordering should be preserved (which it
must because the LSP shouldn't get rewritten or rebuilt).  If one were to
change the tag at, say, an abr, the checksum could change.  I am not sure if
the checksum should change in an LSP!  

Which brings me to the area of summarization.  If multiple TLV 135s with
SubTLV 1 or 2 are contributing to the aggregate, what do we do with the
aggregate's tags?  If we take the community approach, we would merge all the
tags or wipe them.  However, merging them could pose scaling problems.  Is
it necessary?  What about if we take the intersection of all tags, such that
there is no overlap and no duplication?  Then again, for simplicity, we can
just wipe the tags at the summarization point, as is done with atomic
aggregates. 

Further, if we are to define a tag for communities, does this need to be
stated explicitly?  As I see it, the interpretation is implementation and
situation-dependent.  If all are in agreement, I will remove this ambiguity
with an explicit statement as such.

>Reserving tag-space is a fine idea albeit I would probably not 
>put it into a draft, too restrictive for other deployment 
>approaches IMO.

Agreed.  The implied reservations from the communities would be sufficient.
For simple dimensionless tags, no need for reservation.

>I don't think that e.g. indicating whether the set is ordered 
>or not is necessary but we could do it by stealing e.g. one 
>bit from the sub-TLV length. But then pretty soon you end up 
>in the discussion with BGP attribute problem, so e.g. is it 
>mandatory to understand those tags & so on. Not productive really.
>
>
>> >From an operational perspective, we use community ordering and rely 
>> >upon
>> matching rules that expect ordering.  The use of tags for community 
>> support implies a string or sequence, which was not the original 
>> intention.  Were it so, then the wording should change to 
>indicate as 
>> such.
>>
>> > Otherwise if different implementations make assumptions about what 
>> > duplicates mean or assume ordering of tags, you may end up with 
>> > interoperability problems.
>>
>> We should clarify this now before resubmittal.
>
>that was my idea. I know my comments are slightly 'meta' but I 
>kind of blindly try to apply pattern matching in terms of 
>having seen same kind of structures in other protocol designs 
>and the problems that came out from
>over- or underspecification of those structures. I got a clear 
>match here ;-)

Thanks for sharing your insight!

chris

>Summarizing, IMO
>if you care for interoperable implementations, I would spell 
>out the assumptions or lack thereof and maybe give your example.
>
>    thanks
>
>    - tony
>
>
>
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 12 Apr 2002 01:10:47 +0200

On Thu, Apr 11, 2002 at 03:55:11PM -0400, Martin, Christian wrote:

| Which brings me to the area of summarization.  If multiple TLV 135s with
| SubTLV 1 or 2 are contributing to the aggregate, what do we do with the
| aggregate's tags?  If we take the community approach, we would merge all the
| tags or wipe them.  However, merging them could pose scaling problems.  Is
| it necessary?  What about if we take the intersection of all tags, such that
| there is no overlap and no duplication?  Then again, for simplicity, we can
| just wipe the tags at the summarization point, as is done with atomic
| aggregates. 

maybe i am too radical towards aggregates, but IMHO an aggregate is a new
route and thus all the tags should get removed; (solves also the scaling
problem)

the particular problem we are trying to solve using admin-tags is
to control the flow of /32 routes - the aggregate discussion 
is really a corner-case in that respect;

from a implementation point you can always define via local-policy
what admin-tags should be included/suppressed in the aggregate;

| Further, if we are to define a tag for communities, does this need to be
| stated explicitly?  As I see it, the interpretation is implementation and
| situation-dependent.  If all are in agreement, I will remove this ambiguity
| with an explicit statement as such.

i am fine with removing the ambiguity;

/hannes

---

From: Naiming Shen <[email-masked]>
Date: Thu, 11 Apr 2002 16:37:04 -0700

I agree. this tag tlv is only defined in ISIS LSP, how to inject to or
extract the meaning from the tags for each individual isis route is
an implementation and configuration issue. For summarization, there
may exist a reverse issue, if seeing this kind of tag, then don't
summerize it during route leaking or redistribution for example,
but that's also a local config policy issue.

thanks.

 ] On Thu, Apr 11, 2002 at 03:55:11PM -0400, Martin, Christian wrote:
 ] 
 ] | Which brings me to the area of summarization.  If multiple TLV 135s with
 ] | SubTLV 1 or 2 are contributing to the aggregate, what do we do with the
 ] | aggregate's tags?  If we take the community approach, we would merge all t
he
 ] | tags or wipe them.  However, merging them could pose scaling problems.  Is
 ] | it necessary?  What about if we take the intersection of all tags, such th
at
 ] | there is no overlap and no duplication?  Then again, for simplicity, we ca
n
 ] | just wipe the tags at the summarization point, as is done with atomic
 ] | aggregates. 
 ] 
 ] maybe i am too radical towards aggregates, but IMHO an aggregate is a new
 ] route and thus all the tags should get removed; (solves also the scaling
 ] problem)
 ] 
 ] the particular problem we are trying to solve using admin-tags is
 ] to control the flow of /32 routes - the aggregate discussion 
 ] is really a corner-case in that respect;
 ] 
 ] from a implementation point you can always define via local-policy
 ] what admin-tags should be included/suppressed in the aggregate;
 ] 
 ] | Further, if we are to define a tag for communities, does this need to be
 ] | stated explicitly?  As I see it, the interpretation is implementation and
 ] | situation-dependent.  If all are in agreement, I will remove this ambiguit
y
 ] | with an explicit statement as such.
 ] 
 ] i am fine with removing the ambiguity;
 ] 
 ] /hannes

- Naiming

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 11 Apr 2002 18:02:35 -0700

"Martin, Christian" wrote:

> <snip>>

ok

<snip>

> the checksum should change in an LSP!

ok, so if you care for people to interoperate with your vendor of choice for
this particualr application of tags,  spell that stuff out in an example in
the draft I would say.

> with an explicit statement as such.

let's not make that stuff BGP, I think there's anothe rthread going on already
on this stuff but that is one hairy can of worms we're getting in here. I would
agree with Naiming that it is a local policy and default behavior is to not
put anything on summary

    thanks

    -- tony