+1
Regards,
Jeff
> On Feb 16, 2018, at 18:18, Dolganow, Andrew (Nokia - SG/Singapore)
> wrote:
>
> Agree, what Eric has is starting to look like a compromise. Let’s get the
> final text (wip) on the list asap.
>
> Andrew
>
> From: "Les Ginsberg (ginsberg)"
> Date: Friday, February 16, 20
I'm working on a strawman of what I understood we seem to agree on for
further comments in detail, ETA tommorow ...
On Fri, Feb 16, 2018 at 6:18 PM, Dolganow, Andrew (Nokia - SG/Singapore) <
andrew.dolga...@nokia.com> wrote:
> Agree, what Eric has is starting to look like a compromise. Let’s get
Agree, what Eric has is starting to look like a compromise. Let’s get the final
text (wip) on the list asap.
Andrew
From: "Les Ginsberg (ginsberg)"
Date: Friday, February 16, 2018 at 11:08 PM
To: Eric Rosen , Andrew Dolganow
, "(Ice) IJsbrand Wijnands"
Cc: Greg Shepherd , "b...@ietf.org" ,
"
Eric -
From: Eric C Rosen [mailto:ero...@juniper.net]
Sent: Friday, February 16, 2018 6:45 AM
To: Les Ginsberg (ginsberg) ; Dolganow, Andrew (Nokia -
SG/Singapore) ; IJsbrand Wijnands
Cc: Greg Shepherd ; b...@ietf.org; isis-wg@ietf.org;
Xiejingrong ; arkadiy.gu...@thomsonreuters.com
Subject: Re
Perhaps the following would be a good compromise (or perhaps not).
Have an eight-bit field whose values are taken from the "IGP Algorithms"
Registry.
Have another eight-bit field whose values are taken from a new
BIER-specific registry. I don't know, maybe call it the "BIER Underlay
Algorit
Andrew –
There is no change being considered to the size of the algorithm field for
Segment Routing. That is 8 bits – there are mature SR documents and multiple
implementations that use that encoding. There is also the IGP registry defined
in an SR document (though not necessarily exclusively
Well,
Now, there are multiple treads being discussed here under one topic:
- how big should the the field be?
- should there be common registry for all technologies?
- where should it be defined and which WG should standardize it?
To me the first question is totally dependent on the answer to th
I think its clear from the discussion there are different opinions on the
matter on how to make BIER use the BAR field. The reason for me to support 16
bits is that everybody seemed ok go move forward with an 8bits BAR without a
registry, a 16bits BAR does not change anything, its just a bigger
And the registry has already been created:
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types
Les
From: BIER [mailto:bier-boun...@ietf.org] On Behalf Of Greg Shepherd
Sent: Thursday, February 15, 2018 8:39 AM
To: Tony Przygienda
Cc: b...@ietf.org; isis-
On Thu, Feb 15, 2018 at 9:20 AM, Greg Shepherd wrote:
> On Thu, Feb 15, 2018 at 8:53 AM, Tony Przygienda
> wrote:
>
>>
>>
>> On Thu, Feb 15, 2018 at 8:38 AM, Greg Shepherd wrote:
>>
>>> For the record, there is no SR Registry. There is only an IGP Algo Type
>>> Registry as defined in draft-ietf
On Thu, Feb 15, 2018 at 8:53 AM, Tony Przygienda
wrote:
>
>
> On Thu, Feb 15, 2018 at 8:38 AM, Greg Shepherd wrote:
>
>> For the record, there is no SR Registry. There is only an IGP Algo Type
>> Registry as defined in draft-ietf-ospr-segment-routing-extensions-24
>> section 8.5
>>
>
> So is tha
On Thu, Feb 15, 2018 at 8:38 AM, Greg Shepherd wrote:
> For the record, there is no SR Registry. There is only an IGP Algo Type
> Registry as defined in draft-ietf-ospr-segment-routing-extensions-24
> section 8.5
>
So is that a good idea, having multiple drafts in flight with fields
expecting to
For the record, there is no SR Registry. There is only an IGP Algo Type
Registry as defined in draft-ietf-ospr-segment-routing-extensions-24
section 8.5
More inline:
On Thu, Feb 15, 2018 at 8:25 AM, Tony Przygienda
wrote:
> Under 8-bit artistic license granted by Acee herewith ;-)
>
> First, I
Under 8-bit artistic license granted by Acee herewith ;-)
First, I want to emphasize that this is IETF LC (called by Greg as
shepherding WG chair) which means chairs have no further function so we all
can only speak as individuals only .
2nd, I oppose any suggestion to align any kind of SR regist
Ice's reasoning makes sense to me.
On 2/15/2018 3:11 AM, IJsbrand Wijnands (iwijnand) wrote:
Hi Folks,
I support 16 bits because of the following reasons.
For me it would make sense to align the Algorithm value to the "IGP
Algorithm" registry. This registry is defined in:
https://tools.ietf.
Hi Folks,
I support 16 bits because of the following reasons.
For me it would make sense to align the Algorithm value to the "IGP Algorithm"
registry. This registry is defined in:
https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-24#section-8.5
In my opinion, this is going
+1
I’d really like to see justification for anything larger than 8 bits.
Regards,
Jeff
> On Feb 14, 2018, at 18:30, Acee Lindem (acee) wrote:
>
> I agree. As a point of reference, we've only have defined two IGP algorithms
> so far and the segment routing draft dates back about 4 years.
>
>
I agree. As a point of reference, we've only have defined two IGP algorithms so
far and the segment routing draft dates back about 4 years.
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types
Even with more artistic freedom afforded to multicast, I still be
Guys,
I would think 8 bits are sufficient. Others (like SegRtg mentioned below also
use 8). 8 bits gives us tons of room to grow - especially since we have only a
single value defined currently (SFP 0). If we have clear use cases that show us
running out of 8 bits or getting close to that we ca
Hi Arkadiy,
I checked the latest and
for reference and comparing,
and they both use a 8 bits Algorithm.
One of the description: "Algorithm: Single octet identifying the algorithm."
Interesting to use more than 8 bits for BIER's future flexibility :-)
Regards,
XieJingrong
-Original Mess
20 matches
Mail list logo
