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

From: Leeyoung <[email-masked]>
Date: Mon, 1 Dec 2014 21:00:24 +0000

Hi Adrian,

Thanks for providing further comment. Please see in-line for my response to your comment.

Best regards,
Young

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Sunday, November 30, 2014 7:02 AM
To: Leeyoung; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Mail regarding draft-ietf-ccamp-general-constraint-encode

Hi Young,

I've taken the email you attached and copied in the relevant parts below.

This is good progress and everything I have deleted is a good change.

This leaves us with just a few remaining points...

>> Section 2 uses [RWA-Info] in a normative way. Please move
>> the referenced document into the Normative References
>> section.
>
> YOUNG>> When I moved [RWA-Info] to normative reference, the 
> IDINIT gave me an error, so I moved it back to where it was. 

I think the issue that idnits will report is that this reference
is to a downref to an informational I-D.

Two points:
1. Don't worry about it being a reference to an I-D. That draft 
   has completed IETF last call and is in IESG evaluation. It will
   be an RFC before this I-D becomes an RFC.
2. A downref is what it is. You make a normative reference to an
   informative document, you create a downref. But that's OK. Just
   do what you have to do and we call it out in IETF last call.

So, if [RWA-Info] is used as a normative reference, just make the
change. If you don't think it is, or you think it should not be,
then we can have that discussion.

YOUNG>> I think [RWA-Info] is a normative reference. I will make change. 
---

>> Section 2.3
>>
>>   All Local Interface IP Address are supplied in
>>   the context of the advertising node
>>
>> Aren't IP addresses scoped a little more widely?
>
> YOUNG>> Not sure if you meant IPv6? If so, why is it a little
> more widely? 

Sorry, I was too terse.

You write that the IP addresses are supplied "in the context of" the
advertising node. I wonder what that means. 

I think this is the result of a bad block copy. You have...

         0 -- Link Local Identifier

   Indicates that the links in the Link Set are identified by link
   local identifiers. All link local identifiers are supplied in the
   context of the advertising node.

...which is perfectly reasonable.

So you probably just mean...

         1 -- Local Interface IPv4 Address

         2 -- Local Interface IPv6 Address

   Indicates that the links in the Link Set are identified by Local
   Interface IP Address.

YOUNG>> Yes, it is clear. I would delete "All Local Interface IP Address are supplied in the context of the advertising node." 

---

>> Section 2.4
>>
>> Priority needs some explanation or reference. Priority with
>> respect to what?
>>
>>   At least one priority
>>   level MUST be advertised that, unless overridden by local policy,
>>   SHALL be at priority level 0.
>>
>> I cannot parse this at all! 
>
> YOUNG>> Priority is applied to the LSPs being setup or backup
> LSPs being setup. This field gives what labels are available to
> certain priority level associated with LSPs. I would add:

Oh. Are you modelling this on the bandwidth availability fields of the
Interface Switching Capability Descriptor sub-TLV of the Link TLV in 
OSPF for GMPLS?

YOUNG>> Yes. 

You appear to be suggesting that some labels can be reserved for use by
LSPs of specific priorities. This is stricter and more constraining than
the bandwidth partitioning described in RFC 4202, but that's OK if that 
is what people want to do.

YOUNG>> Yes. 

> Note that the PRI flag identifies the priority of the LSP which is
> being set up. (Section 2.4)
>
> Note that the PRI flag identifies the priority of the backup LSP 
> which is being set up. (Section 2.5)

I think some more careful text is needed. The point I want to draw out
is that the priority you are describing here is not the priority of the
LSP being set up (which is what you are writing) but the availability 
of a label for use by an LSP of a specific priority if an attempt is 
made to set one up.

YOUNG>> Yes, how about the following?: 

Note that the PRI flag identifies the availability of a label for use by an LSP of a specific priority if an attempt is made to set one up. (Section 2.4)

Note that the PRI flag identifies the availability of a label for use by a backup LSP of a specific priority if an attempt is made to set one up. (Section 2.5)

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. 

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

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

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? 

> How about:
>
>OLD:
>   At least one priority level MUST be advertised that, unless
>   overridden by local policy, SHALL be at priority level 0.
>NEW: 
>   At least one priority level MUST be advertised. 

This change is fine, but on its own it doesn't address the other issues.

YOUNG>> I hope this is related with the above explanation. 

---

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

---

And finally, a new point, I'm afraid. Section 2 says...

   The encodings are
   designed to be suitable for use in the GMPLS routing protocols OSPF
   [RFC4203] and IS-IS [RFC5307] and in the PCE protocol (PCEP)
   [RFC5440].

It may be true that you have designed this information to be used in
PCEP, but PCEP doesn't carry resource availability information. Doesn't
that mean that designing for use in PCEP is "ambitious"?

YOUNG>> PCEP for WSON is coming along... :) At least some if not all may be applicable, which is yet to be determined. 

Thanks for the work,
Adrian

> -----Original Message-----
> From: Leeyoung [mailto:[email-masked]]
> Sent: 24 November 2014 06:38
> To: [email-masked]; draft-ietf-ccamp-general-constraint-
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [CCAMP] Mail regarding draft-ietf-ccamp-general-constraint-encode
> 
> Hi Adrian,
> 
> Attached is an email I sent (on Nov 4) in response to your AD review. Please
let
> me know if you have any question.
> 
> Thanks,
> Young
> 
> -----Original Message-----
> From: CCAMP [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Sunday, November 23, 2014 2:49 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [CCAMP] Mail regarding draft-ietf-ccamp-general-constraint-encode
> 
> Hello,
> 
> Where do we stand on a revision of this I-D to address my review?
> 
> This is gating progress of
> - draft-ietf-ccamp-wson-signaling
> - draft-ietf-ccamp-wson-signal-compatibility-ospf
> - draft-ietf-ccamp-gmpls-general-constraints-ospf-te
> - draft-ietf-ccamp-rwa-wson-encode
> 
> Thanks,
> Adrian
> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Mon, 01 Dec 2014 18:15:21 -0500

Young,
	Please keep in mind that *any* changes that impact behavior on the wire
will need to be reviewed by the WG.  Changes in requirements language is
pretty easy to make, but changing field sizes is another matter. -- Not
saying it can't be done, and in fact, better now than in the field, but
changes should be explicitly reviewed and discussed in the WG.

Keep going as is, and let the WG know once a change is warranted.

Lou

---

From: Leeyoung <[email-masked]>
Date: Mon, 1 Dec 2014 23:19:00 +0000

Lou,

Absolutely, if there are any changes such as field sizes, I will inform the WG of the change. I hope we don't have to go into that. 

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Monday, December 01, 2014 5:15 PM
To: Leeyoung; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [CCAMP] Mail regarding draft-ietf-ccamp-general-constraint-encode

Young,

Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 01 Dec 2014 19:18:54 -0500

Inform ... and wg support ...

Lou

On December 1, 2014 6:19:31 PM Leeyoung <[email-masked]> wrote:

> Lou,
>
> Absolutely, if there are any changes such as field sizes, I will inform the 
> WG of the change. I hope we don't have to go into that.
>
> Thanks,
> Young
>
> To: Leeyoung; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> > Subject: RE: [CCAMP] Mail regarding 
> draft-ietf-ccamp-general-constraint-encode
> >
> > Hi Young,
> >
> > YOUNG>> Yes, it is clear. I would delete "All Local Interface IP Address 
> are supplied in the context of the advertising node."
> >
> > ---
> >
> >>> Section 2.4
> >>>
> > Note that the PRI flag identifies the availability of a label for use by 
> an LSP of a specific priority if an attempt is made to set one up. (Section 
> 2.4)
> >
> > Note that the PRI flag identifies the availability of a label for use by 
> a backup LSP of a specific priority if an attempt is made to set one up. 
> (Section 2.5)
> >
> >
> > 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.
> >
> >
> > 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.
> >
> > "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."
> >
> > 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?
> >
> >> How about:
> >>
> >> OLD:
> > YOUNG>> PCEP for WSON is coming along... :) At least some if not all may 
> be applicable, which is yet to be determined.
> >
> > Thanks for the work,
> > Adrian
> >
> >
> >> Subject: RE: [CCAMP] Mail regarding 
> draft-ietf-ccamp-general-constraint-encode
> >>
> >> Hi Adrian,
> >>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 2 Dec 2014 12:13:30 -0000

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

Trimming down still further...

> 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>> 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.
> 
> "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>> Actually, to encode priority 7, it should be [1 1 1 1 1 1 1 1]. Please
note
> the description:
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.

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?)

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>> Should I increase the Num Labels to be 20 bits if that makes you

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!

---

From: Leeyoung <[email-masked]>
Date: Tue, 2 Dec 2014 16:57:09 +0000

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:[email-masked]] 
Sent: Tuesday, December 02, 2014 6:14 AM
To: Leeyoung; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Mail regarding draft-ietf-ccamp-general-constraint-encode

be
LSP). In
of
is not

YOUNG>> Thanks, will include the suggested text. 

is
Priority "N"
advertised as

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

note
sub-TLV,

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

integer. I
Priority
it was

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

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)

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 28 Dec 2014 15:56:44 -0000

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/

> Sent: 02 December 2014 16:57
> 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
> 
can
> > "For preemption, the following rule applies: When a label is marked by an
LSP
> > YOUNG>> Good question. I think the best choice is the last case. Once a
label
> 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:
> 
> 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
> YOUNG>> I would stick to what it is. I added the description clear: "If a
label is
> available at

---

From: Leeyoung <[email-masked]>
Date: Mon, 29 Dec 2014 22:46:58 +0000

Adrian,

Thanks for your giving attention to this draft and commenting further. Here's my comment, please see in-line. After this revision, I think it will be a good time to solicit comments from WG. 

Best regards,
Young

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Sunday, December 28, 2014 9:57 AM
To: Leeyoung; [email-masked]
Cc: [email-masked]
Subject: RE: [CCAMP] Mail regarding draft-ietf-ccamp-general-constraint-encode

Thanks,
Adrian

---

> {sr port, src label, sdt port, dst label}. 

OK, NEW: {src port, src label, dst port, dst label}

---

Section 2

YOUNG>> Yes, that is what is intended. 
---

Section 2.4

YOUNG>> Make sense. Corrected. 
---

In 2.5

  If a label is available

YOUNG>> Agree. Corrected here and in Section 2.4 as well. 
---

YOUNG>> Yes, thanks. Corrected. 

---

In Section 2.5
s/2.5/2.4/

YOUNG>> Yes, thanks. 

Diff-marked
can
LSP
label
0--
priority N
and once
advertised
WG
additional
label is