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

[Leeyoung <[e-mail]>]

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:[e-mail]] 
Sent: Sunday, November 30, 2014 7:02 AM
To: Leeyoung; [e-mail]
Cc: [e-mail]
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:[e-mail]]
> Sent: 24 November 2014 06:38
> 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,
> 
> 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:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Sunday, November 23, 2014 2:49 AM
> To: [e-mail]
> Cc: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp