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

["Adrian Farrel" <[e-mail]>]

Looks like no-one in the WG had anything to say about these changes. I was
hoping someone else was reading them, after all, the WG (and perhaps your
co-authors) is supposed to be interested in publication of the document.

Well, since you were waiting for me before posting a revision, here are my
comments. After you have fixed them, please post a new version and we will
continue.

Thanks,
Adrian

---

New text in Section 2 has some typos
> {sr port, src label, sdt port, dst label}. 

---

Section 2
When you reduced the Connectivity field to 4 bits you moved the Matrix ID field
onto a 4 bit boundary. That's OK if it is what you want to do, but it is also
unusual.

---

Section 2.4
I think your new text is not quite right.

> 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.  

I don't think this makes sense. You seem to be trying to say two things in one
paragraph. Perhaps...

When a label is advertised as available for priorities 0, 1, ... M it may be
used by any LSP of priority N <= M.
When a label is in use by an LSP of priority M is may be used by an LSP of
priority N < M if LSP preemption is supported.

---

In 2.5
> If a label is available
> at priority M it MUST be available at each priority N < M.

Yeah, but you need to say what has to be in the advertisement. So...

  If a label is available
  at priority M it MUST be advertised as available at each priority N < M.

Otherwise people will think that setting just one bit is OK and that the
availability at other priorities is inferred.

---

The length field in your final example in A.2 seems to have got worse!
8*4=32 (I think)

---



In Section 2.5
> The same LSP set up and pre-emption rules specified in Section 2.5  
> apply here. 
s/2.5/2.4/





> -----Original Message-----
> From: Leeyoung [mailto:[e-mail]]
> Sent: 02 December 2014 16:57
> To: [e-mail]; draft-ietf-ccamp-general-constraint-
> [e-mail]
> Cc: [e-mail]
> Subject: RE: [CCAMP] Mail regarding draft-ietf-ccamp-general-constraint-encode
> 
> 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.
> 
> 
>