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

[Leeyoung <[e-mail]>]

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:[e-mail]] 
Sent: Monday, December 01, 2014 5:15 PM
To: Leeyoung; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: [CCAMP] Mail regarding draft-ietf-ccamp-general-constraint-encode

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

On 12/01/2014 04:00 PM, Leeyoung wrote:
> 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
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>