Hi Hannes,
Thanks for pointing this out:
> On Dec 7, 2023, at 4:38 AM, Hannes Gredler
> wrote:
>
> We have used similar textblocks for the OSPFv2 and OSPFv3 SR extensions and I
> am not aware
> of any questions from implementators around ambiguity.
I checked RFCs 8665 and 8666, and they
Hi Acee,
> On Dec 7, 2023, at 3:44 PM, Acee Lindem wrote:
>
> We’ll probably never BIS these RFCs but I would agree that it would be good
> for one of the RFC authors to provide a clearer definition of the
> relationship between the L flag, V flag, TLV length, and TLV values (label,
> index,
..@gmail.com; Jeff Tantsura ; Peter
> Psenak (ppsenak) ; Horneffer, Martin
> ; wim.henderi...@nokia.com;
> edc.i...@gmail.com; ro...@google.com; milojevici...@gmail.com;
> s...@ytti.fi; lsr
> Subject: Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label
>
> Hi Les,
>
>
Hi Les,
> On Dec 7, 2023, at 4:03 PM, Les Ginsberg (ginsberg)
> wrote:
>
> Let's be careful here.
Certainly. I don't think we've been proceeding recklessly so far, have we?
> SR-MPLS has been deployed for several years, there are multiple
> implementations which have demonstrated
; Jeff Tantsura
> > mailto:jefftant.i...@gmail.com>>; Peter Psenak
> > (ppsenak) mailto:ppse...@cisco.com>>;
> > Horneffer, Martin > <mailto:martin.hornef...@telekom.de>>;
> > wim.henderi...@nokia.com <mailto:wim.henderi...@nokia.com>;
> > edc.i.
itkows.i...@gmail.com; Jeff Tantsura
> ; Peter Psenak (ppsenak) ;
> Horneffer, Martin ;
> wim.henderi...@nokia.com; edc.i...@gmail.com; ro...@google.com;
> milojevici...@gmail.com; s...@ytti.fi; lsr
> Subject: Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label
>
>
Hi John,
> On Dec 7, 2023, at 12:22, John Scudder
> wrote:
>
> Hi Hannes,
>
>> On Dec 7, 2023, at 4:38 AM, Hannes Gredler
>> wrote:
>>
>> We have used similar textblocks for the OSPFv2 and OSPFv3 SR extensions and
>> I am not aware
>> of any questions from implementators around
Hi Hannes,
> On Dec 7, 2023, at 4:38 AM, Hannes Gredler
> wrote:
>
> We have used similar textblocks for the OSPFv2 and OSPFv3 SR extensions and I
> am not aware
> of any questions from implementators around ambiguity.
Thanks for the pointer, I’ll take a look at those, too.
> IMO there is
Hi John,
Section 2.1 defines also the bits to be used in the flags field:
where:
[ ... ]
V-Flag:
Value Flag. If set, then the Prefix-SID carries a value (instead of an index).
By default, the flag is UNSET.
L-Flag:
Local Flag. If set, then the value/index carried by the Prefix-SID has local
Hi Les,
Thanks for the speedy reply, and I take your point. I do still think an erratum
is called for, but I think it's editorial or "hold for document update", not
technical. Now that you've applied the clue bat I think I can compose one. I'll
do so by and by and you can see what you think.
John -
The meaningful bits of the SID and the size (number of octets) depend upon the
flags. As Section 2.1.1.1 states (emphasis added):
The following settings for V-Flag and L-Flag are valid:
The V-Flag and L-Flag are set to 0:
The SID/Index/Label field is a 4-octet index defining
Hi Authors and Contributors who "should be considered as coauthors”,
Your RFC defines the SID/Index/Label field of the Prefix Segment Identifier
(Prefix-SID) Sub-TLV, in Section 2.1, as:
SID/Index/Label as defined in Section 2.1.1.1.
But when I look at Section 2.1.1.1 I see that it
12 matches
Mail list logo
