Re: [mpls] mail on ISD encodding

[[e-mail]]

Tony,

Inline please.

Sorry, if I misunderstood, if you are saying that we should leave bit
20 as the p-bit, and use e.g. bit 24 as a "D-bit", indicating that
this Format B is followed by a Format D LSE, that is fine with me. If
you can convince me that the NAL is not needed (no Format C, no NAL).

 >
> [WG chair hat: off]
>
> Hi Loa,
>
>
>> So you mean we should first break what is not broken, then "steal a bit"
>> for the U-bit, that was there from the start?
>
>
> I don’t understand this comment.
>
> As your original example showed, we currently cannot attach Format D LSEs
> after Format B LSEs.  I proposed one way of allowing that, which would
> hopefully make some common cases more efficient as there would be fewer
> cases where there would be a NOP opcode in the Format B LSE.
>
> You objected to my proposal saying that we should have at least one
> reserved bit. I’m fine with that, we can simply take one more bit from
> the Format B data space.

Sorry, if I misunderstood, if you are saying that we should leave bit
20 as the p-bit, and use e.g. bit 24 as a "D-bit", indicating that
this Format B is followed by a Format D LSE, that is fine with me. If
you can convince me that the NAL is not needed (no Format C, no NAL).

>
>> Or did you mean steal for
>> the p-bit which also seems unnecessary, since the R-bit sits there in
>> draft-ietf-mpls-mna-hdr, and draft-jags-mpls-ps-mna-hdr nicely allocates
>> it as a p-bit? How about just leaving the bit allocation as is?
>
>
> I cannot follow this at all.
>
> In any case, I take it that you dislike my proposal. That’s fine.

I do dislike making it impossible to not use the R-bit for PSD indication.
The rest is possibly fine.
>
>
>> However, there is one thing about where the allocations are done.
>>
>> The p-bit is one of the ISD-flags, it points at OSD, but it is really a
>> piece of the ISD. Should be allocated in the draft-ietf-mpls-mna-hdr.
>
>
> I disagree.  As I mentioned, in the ISD header, that should simply be a
> reserved bit.  It should not be assigned for PSD.

I think to assign it for PSD now is the most straightforward approach.
But I would like to hear from the rest of the authors' of the two
drafts and the MPLS folks in general.

> We may never use PSD.
> It would be poor engineering to prevent its use in perpetuity.  If we do
> not use PSD, then that reserved bit might be pressed into service for some
> other purpose.
>
> Flexiblity in future design would seem to be an overriding principle here.
>
>
>> Also the instruction (for R-bit), "set to zero when sending and ignore
>> when received" is problematic. Let us forget about the R-bit and put the
>> p-bit where it belongs. There should be a description of how
>> a non-PSD capable node treats a packet with the p-bit set.
>
>
> I disagree.  That is how we always deal with reserved bits.

Sorry, there is a difference between the general "Reserved" and the
specific "Reserved for" that we are discussing here.

If we (or our grandchildren) decide to use the R-bit as p-bit, only
some LSRs are updated in the first round, then there is a risk, that
a packet with the p-bit in the Format B LSE. arrives at this node, but the
p-bit is ignored, it would be better if the bit was not ignored,
but that the LSR understood that there are PSD after the stack and that
LLSR could have an option for what to do with the packet, including
sending
error messages.

>
> There is no point in arguing about PSD and non-PSD nodes until we decide
> to commit to PSD.

I have agreed (calling consensus as a wg chair) that ISD is needed. I
still think so, but mostly for flags. I'm concerned about pushing "huge"
amounts
of ancillary data into the stack, which makes it grow with 10 to 20 LSEs
is not a good thing. The figures I hear is that a label stack depth of more
7-8 LSEs are problematic for a substantial part of the deployed LSRs.

/Loa
>
> Tony
>
>