headers
Tony Przygienda | 1 Jun 2003 12:03
Picon

Re: RE: Comments on <draft-ietf-isis-admin-tages-01.txt>

Acee Lindem wrote:

> Hannes,
>
> If we agree that having a single 32 bit and/or 64 bit tag is a
> good idea then perhaps we could change the wording of the draft to
> say that an implementation SHOULD only send and interpret a single
> tag and SHOULD ignore data past the first tag. This would allow
> the usage of multiple tags to be gracefully deprecated.
>
> If this isn't acceptable then can we can agree on a small
> finite/known number of tags with suggested usage? 

So, I watched for a while Alex and now Acee trying to influence the
direction of this thing (after a last call funny enough) and I definitely
do _NOT_ like the direction this is going.  I have an understanding for
'exact specification' and 'understanding what the tags are doing' and
'we don't want 64 and 32 bits in place' __BUT__

1) Slashing the whole thing to things like 1 tag  only and squeezing it
    in size may feel good in terms of specification but it will probably
make
    it as flexible and useful as the OSPF tag, namely completely useless.
    Just look at the unnatural contortions of RFC 1994.
2) I am lacking to follow the arguments here why multiple tags are so
harmfull,
    why we have to know _exactly_ what every tag means and why the
    32 and 64 bit tags together are such a big issue. The only ones
    I saw were basically 'it may blackhole routes or lead to problems
    when misconfiguration or implementaion errors occur'. Well, guess
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tony Przygienda | 1 Jun 2003 12:20
Picon

Re: RE: Comments on <draft-ietf-isis-admin-tages-01.txt>

>
>
>I would strongly encourage keeping multiple, ordered tags
>
oops, glas of wine here, it's   'not-ordered'  ...

    -- tony
Permalink | Reply | 0 comments |
headers
Acee Lindem | 1 Jun 2003 13:28

Re: RE: Comments on <draft-ietf-isis-admin-tages-01.txt>


Tony Przygienda wrote:
> Acee Lindem wrote:
> 
> 
>>Hannes,
>>
>>If we agree that having a single 32 bit and/or 64 bit tag is a
>>good idea then perhaps we could change the wording of the draft to
>>say that an implementation SHOULD only send and interpret a single
>>tag and SHOULD ignore data past the first tag. This would allow
>>the usage of multiple tags to be gracefully deprecated.
>>
>>If this isn't acceptable then can we can agree on a small
>>finite/known number of tags with suggested usage? 
> 
> 
> So, I watched for a while Alex and now Acee trying to influence the
> direction of this thing (after a last call funny enough) and I definitely
> do _NOT_ like the direction this is going.  I have an understanding for
> 'exact specification' and 'understanding what the tags are doing' and
> 'we don't want 64 and 32 bits in place' __BUT__
> 
> 1) Slashing the whole thing to things like 1 tag  only and squeezing it
>     in size may feel good in terms of specification but it will probably
> make
>     it as flexible and useful as the OSPF tag, namely completely useless.
>     Just look at the unnatural contortions of RFC 1994.
> 2) I am lacking to follow the arguments here why multiple tags are so
> harmfull,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tony Przygienda | 1 Jun 2003 13:55
Picon

Re: RE: Comments on <draft-ietf-isis-admin-tages-01.txt>

>
>
>>
>>
>> I would strongly encourage keeping multiple, ordered tags and the draft
>> not touching on their application. I would also encourage a 32 and a
>> 64 bit tag, both being independent address spaces. It's not ideal but
>> what's the point redoing stuff in the field just so the encoding is tad
>> nicer? I would encourage a draft on how the 2547 stuff is being sloshed
>> around using tags. And I think we added a paragraph that when the
>> route selection supresses a route based on a tag we may end up with
>>  a blackhole.
>
>
> So if we step back, what we have here is a pair of generic TLVs (32
> and 64 bits tags) which can be used to send an arbitrary amount of
> opaque information. 

yes, you could send in 64 bit tags Finnegan's Wake up to couple hundred
bytes per prefix if you really want to but then, I assume to fix this
problem in OSPF
you will decleare RFC2370 unlawfull really soon?
If the 'hidden communication channel' is the problem you
try to solve, security groups will yield a much more fruitfull harvest.

> Will the tag encodings and their respective
> applications be described in future drafts? 

That would be very, very desirable but given e.g. EXTCOMMs realities,
may only partially come to fruition. I would expect that stuff that has to
(Continue reading)

Permalink | Reply | 1 comment |
headers
Acee Lindem | 1 Jun 2003 15:34

Re: RE: Comments on <draft-ietf-isis-admin-tages-01.txt>


Tony Przygienda wrote:
>>
>>>
>>>I would strongly encourage keeping multiple, ordered tags and the draft
>>>not touching on their application. I would also encourage a 32 and a
>>>64 bit tag, both being independent address spaces. It's not ideal but
>>>what's the point redoing stuff in the field just so the encoding is tad
>>>nicer? I would encourage a draft on how the 2547 stuff is being sloshed
>>>around using tags. And I think we added a paragraph that when the
>>>route selection supresses a route based on a tag we may end up with
>>> a blackhole.
>>
>>
>>So if we step back, what we have here is a pair of generic TLVs (32
>>and 64 bits tags) which can be used to send an arbitrary amount of
>>opaque information. 
> 
> 
> yes, you could send in 64 bit tags Finnegan's Wake up to couple hundred
> bytes per prefix if you really want to but then, I assume to fix this
> problem in OSPF
> you will decleare RFC2370 unlawfull really soon?

Actually, to the best of my knowledge, most of the opaque LSA applications
are documented in RFCs and/or drafts (although I know there are undocumented
TLVs sent within TE LSAs).

>     thanks
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tony Li | 1 Jun 2003 21:09

Tags


A thought:

What would happen if we did something similar to BGP communities?

To wit:

- multiple tags
- unordered
- 32 bits only
- global and local scoping

Tony
Permalink | Reply | 1 comment |
headers
Tony Przygienda | 1 Jun 2003 22:10

Re: Tags

Tony Li wrote:

>A thought:
>
>What would happen if we did something similar to BGP communities?
>
>To wit:
>
>- multiple tags
>- unordered
>- 32 bits only
>- global and local scoping
>
>Tony
>  
>
That's exactly what I'm calling for as well (except if we do just one,
64 for me)
and I thought we had more or less nailed with the draft so far.
The global vs. local scoping (I asume you mean transitive or not in BGP
speech)
I don't  deem that important since it's an IGP so across-domain doesn't mean
much to me in this context ...

    thanks

    -- tony

>  
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tony Li | 1 Jun 2003 22:45

RE: Tags


|    >A thought:
|    >
|    >What would happen if we did something similar to BGP communities?
|    >
|    >To wit:
|    >
|    >- multiple tags
|    >- unordered
|    >- 32 bits only
|    >- global and local scoping
|    >
|    That's exactly what I'm calling for as well (except if we 
|    do just one,
|    64 for me)
|    and I thought we had more or less nailed with the draft so far.
|    The global vs. local scoping (I asume you mean transitive 
|    or not in BGP
|    speech)
|    I don't  deem that important since it's an IGP so 
|    across-domain doesn't mean
|    much to me in this context ...

I'm not seeing a big win with 64 bits, but can be convinced.

By local & global scoping, I was suggesting that we divide the
range to cover both globally well-known values and also have
locally defined/vendor defined values.

Tony
(Continue reading)

Permalink | Reply | 668 comments |
headers
Tony Przygienda | 1 Jun 2003 22:59

Re: Tags

Tony Li wrote:

>
>|    >A thought:
>|    >
>|    >What would happen if we did something similar to BGP communities?
>|    >
>|    >To wit:
>|    >
>|    >- multiple tags
>|    >- unordered
>|    >- 32 bits only
>|    >- global and local scoping
>|    >
>|    That's exactly what I'm calling for as well (except if we 
>|    do just one,
>|    64 for me)
>|    and I thought we had more or less nailed with the draft so far.
>|    The global vs. local scoping (I asume you mean transitive 
>|    or not in BGP
>|    speech)
>|    I don't  deem that important since it's an IGP so 
>|    across-domain doesn't mean
>|    much to me in this context ...
>
>
>I'm not seeing a big win with 64 bits, but can be convinced.
>
ok
(Continue reading)

Permalink | Reply | 1 comment |
headers
Danny McPherson | 2 Jun 2003 00:29
Favicon

Re: Tags

On 6/1/03 2:59 PM, "Tony Przygienda" <prz <at> xebeo.com> wrote:

>> I'm not seeing a big win with 64 bits, but can be convinced.
>> 
> ok

If the option is 32 or 64,  I'd prefer 64, else I suspect we'll see
something akin to "IS-IS extended-tags" draft in the near future [Hrmm.,
perhaps 32 bits is a good idea].

>> 
>> By local & global scoping, I was suggesting that we divide the
>> range to cover both globally well-known values and also have
>> locally defined/vendor defined values.
>> 
> agreed

What would the initial set of well-known values look like?

-danny
Permalink | Reply | 0 comments |

Gmane