Re: [CCAMP] Mail regarding draft-ietf-ccamp-general-constraint-encode

[Leeyoung <[e-mail]>]

Hi Adrian,

Thanks for your further details. Please see inline for my response. Diff-marked file attached for your check. Please let me know if we need further trimming down or this is ready to move on. Thanks.

Best regards,
Young

-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]] 
Sent: Tuesday, December 02, 2014 6:14 AM
To: Leeyoung; [e-mail]
Cc: [e-mail]
Subject: RE: [CCAMP] Mail regarding draft-ietf-ccamp-general-constraint-encode

I think we're very nearly there. Thanks for chasing the last details.

Trimming down still further...

> >> Section 2.4
>
> You'll also need to explain how this factors in with preemption. Can
> an LSP of priority 0 use a label marked as priority 3? If so, can it
> use it:
> - only when all priority 0, 1, and 2 labels have been used?
> - only when it is not already in use for a priority 1, 2, or 3 LSP?
> - at any time?
> 
> YOUNG>> When a label is marked as priority N, this implies that the label can
be
> usable by any priorities 1, 2, ... N at any time. (This is for setting up an
LSP). In
> regards to preemption, how about the following statement added to the text:
> 
> "For preemption, the following rule applies: When a label is marked by an LSP
of
> priority N and available, an LSP of priority M (M<N) can use it only when it
is not
> already in use."

I think what you are doing here is describing RSVP-TE pre-emption. If so, it is
better to leave that in 3209.

I think you just need text like...

"The PRI field indicates the availability of the labels for use in LSP set up
and pre-emption as described in [RFC3209]."

YOUNG>> Thanks, will include the suggested text. 

> In the light of answers to those questions, how will you advertise
> labels that are already in use on an interface? For example, suppose a
> label was initially advertised as available for priorities, 0, 1, 2, and
> 3. An LSP at priority 2 is set up using this label. Will you now
> withdraw its advertisement (not available) or will you advertise it as
> available at priorities 0 and 1? Or maybe you want to advertise it as in
> use at priority 2 so that path computation can decide whether to
> preempt or not.
> 
> YOUNG>> Good question. I think the best choice is the last case. Once a label
is
> used, then advertise it as in use at priority "N" ("N" in which an LSP at
Priority "N"
> is set up using this label) so that path computation can decide whether to
> preempt or not.
> 
> I would add the following sentence:
> 
> "Once a label is used for an LSP at a priority, say N, then this label is
advertised as
> in use at priority N."

OK, but do you have a way to advertise "in use at priority N"?
I think it could be done with a new field.
Or it could be done by changing "available for 0--M" to "available for 0--(N-1)"
(where N<=M)

YOUNG>> Aha...I would do it by changing "available for 0---M" to available for 0---(N-1) (where N<=M) to avoid introducing a new field. Thanks for this great suggestion. So I would introduce the following text in Section 2.5:

"When a label is marked by an LSP of priority M and available, an LSP of priority N (N<=M) can use it only when it is not already in use."

"When a label was initially advertised as available for priorities, 0, 1,...,M and once a label is used for an LSP at a priority, say N (N<=M), then this label is advertised as available for 0,...,N-1."

And in Section 2.6:

"The same LSP set up and pre-emption rules specified in Section 2.5 apply here."

> > Regarding "At least one priority
> > level MUST be advertised that, unless overridden by local policy,
> > SHALL be at priority level 0." --- I see the issue. There was a mixed
> > up between priority 7 (lowest) and priority 0 (highest). It should
> > have been priority level 0 which is in effect has no priority of
> > labels so that any LSP level can grab such labels.
> 
> What you have written here opens up something equally confusing. The
> field in question is a bit map and is described as
> 
>    A bit MUST be set (1) corresponding to each priority
>    represented in the sub-TLV
> 
> That clearly implies that more than one bit can be set. Yet you are
> saying (I think) that setting bit 7 implies that the label is
> available at all priorities. So why do you need a bit field and not
> a simple integer?
> 
> YOUNG>> Actually, to encode priority 7, it should be [1 1 1 1 1 1 1 1]. Please
note
> the description:
> 
> "A bit MUST be set (1) corresponding to each priority represented in the
sub-TLV,
> and MUST NOT be set (0) when the corresponding priority is not represented. At
> least one priority level MUST be advertised."

While I can accept that the way to encode priority 7 is 0b11111111, the text
doesn't say that! The text says you set one bit for each priority that is
allowed, and that has to be read in conjunction with "if it is available at
priority M it MUST be available at each priority N < M" if you want to arrive at
the right result.

YOUNG>> I would still stick to a bit field (the next discussion) as this was a WG decision. In light of that decision, I agree with you that we need an additional phrase you suggested: "If a label is available at
priority M it MUST be available at each priority N < M" (In Sections 2.5 and 2.6)

But...

> I cannot recall why we decided to use a bit field as opposed to a simple
integer. I
> believe we used a bit field because RFC 3209 uses 8 bits for Setup/Holding
Priority
> in Section 4.7.2, the original contributor of this section/encoding (I believe
it was
> Rajan Rao) used 8 bit field. Do you think this would be a problem?

I really think that using a bit field is just going to cause confusion.
It has led us to spend a lot of time already trying to fathom how the bits are
to be set and interpreted. 
We have ended up with you explaining that if I set bit N I must also set bit n
for n = 0 to N-1.
So, you have stated that there are only 8 valid settings of the PRI field (0,
x80, xC0, xE0, xF0, xF8, xFC, xFE, xFF).
It would seem easier (to me) to have the only 8 settings of the PRI field be (0,
1, 2, 3, 4, 5, 6, 7)

Please note that RFC 3209 uses a one byte field to encode an integer in the
range 0 to 7. Just because there are eight bits available doesn't mean it is a
bit field! (I am now thinking, OMG, how many people have implemented Holding
Priority and Setup Priority as bit fields?)

YOUNG>> I am afraid to say that this happened already in some implementation. 

Now, and to be completely clear, I am not saying to the WG "I wouldn't have done
it like this." The WG is free to choose how to encode PRI.
So, if you want to remain as a bit map, that's OK. You'll just have to spend
some more time getting the description clear.

YOUNG>> I would stick to what it is. I added the description clear: "If a label is available at
priority M it MUST be available at each priority N < M" (In Sections 2.5 and 2.6)

> >> 2.6.3
> >>
> >> Only support 4096 labels in a bitmap set? Really?
> >
> > YOUNG>> Yes, 2 ^^ 12 = 4096. It was originally written in the
> > context of wavelength. Would this be sufficient?
> 
> If you and the WG are OK with this, I suppose I am.
> 
> You have 256 sub-matrices so you are allowing 2^20 labels which is,
> I suppose, a good thing if you are trying to be generic and support
> packet as well as wavelength.
> 
> Of course, the sub-matrix approach does not allow a full 2^20 grid.
> 
> To be clear, my concern is that you make this document (that claims to
> be generic) sufficient to handle all manner of technologies from fine-
> grained OTN, through flexi-grid, Ethernet, and packet.
> 
> Perhaps it is OK to assume that limited cross-connect will be more
> likely in wavelength systems and less likely in fine-grained systems.
> 
> Recall that the worst case is that the label space is entirely
> fragmented so that ranges don't work and every second label must be
> explicitly reported.
> 
> YOUNG>> Should I increase the Num Labels to be 20 bits if that makes you
> comfortable?

Not about making me comfortable! (But thanks for caring :-)
It's about doing the right thing.

Does the WG think it is OK as it is and provides enough scope for generic use?
If so, move on.
If not, what are the implications of allowing up to 2^20 bits in the bit map?
Because that is a lot of bytes!

YOUNG>> I would stay as it is. Thanks.