Subject: Re: [Gen-art] Gen-art LC review of draft-ietf-pce-of-05

From: Robert Sparks <[email-masked]>
Date: Fri, 9 Jan 2009 10:05:49 -0600

Hi Adrian -

The additional text added in -06 to point out the edge cases to the  
implementors was exactly the kind of thing I was suggesting.
Thanks for adding it.

RjS

On Dec 19, 2008, at 10:32 AM, Adrian Farrel wrote:

> Thanks Robert,
> We're converging.
>
>>>> This is probably a naive question, but what happens if a PCC  
>>>> sets  the OF flag in a request, doesn't provide a OF object, and  
>>>> the OF  object in the response has a function code the client has  
>>>> never  heard of before? (If this is clear, where in the document  
>>>> suite is  it captured?)
>>>
>>> The PCC is not required to process the OF object on the PCRep.
>>> If the PCC gets a function code it doesn't understand it can:
>>> - ignore it and use the response
>>> - add the function code to its view of the PCE's repetoire for
>>>   later request/exclusion
>>> - discard the response and ask another PCE to compute for it
>>> - discard the response and ask the same PCE to compute
>>>   excluding the function used.
>>>
>>> I'm not sure we need to tell implementers how to write code here.
>>
>> No, but making it clear to an implementer that this (and the   
>> following) are cases they will to have to deal with would be a  
>> good  thing.
>> Is the list you present above explicit (even if distributed) in  
>> other documents? - I'm definitely not well-versed in this protocol.
>> But I'm more interested in making sure it's clear to implementors  
>> that the conditions can arise than laying out what they have to do  
>> about it  - the conditions are subtle if you read this document  
>> alone.
>
> OK.
> These optional behaviors are not described anywhere.
> They can be added as "suggested potential actions"
>
>>>> Also (and to check my understanding of how extensibility of the   
>>>> flags field in the RP object is supposed to work) - it's  
>>>> possible  for the OF flag to be set in a request but for the  
>>>> response to not  contain an OF object (if the PCE doesn't know  
>>>> about the extension  in this draft it MUST ignore the non-zero  
>>>> flag bit according to  the definitions on page 30 of [PCEP]).  
>>>> Should this document  explicitly mention this case?
>>>
>>> Right, this would be the behavior of a legacy node.
>>> The PCC that set the OF flag would receive a PCRep carrying no OF   
>>> object (i.e., in breach of this I-D).
>>> The PCC would either:
>>> - discard the PCRep because it *really* wanted the OF object  
>>> returned
>>> - shrug its shoulders and continue
>>>
>>> Again, I'm not sure that we need to tell people how to write  
>>> code.  This certainly doesn't change the protocol behavior onthe  
>>> wire.
>> see above
>
> Ditto
>
>>>> This draft uses RBNF (draft-farrel-rtg-common-bnf). The proto   
>>>> writeup indicates that no tool was used to verify the RBNF in  
>>>> the  draft. Has there been a careful review by a human? (There  
>>>> isn't  much of it, but enough for a typo or dangling reference to  
>>>> slip in).
>>>
>>> Did you find any problems?
>>
>> No, but I didn't try to either.
>>
>> Spot-checking a couple of things:
>>
>> Some productions use <SVEC-list> but the rule I think they're  
>> pointing  to is <svec-list>. ([PCEP] is similar). Are the rule  
>> names supposed to  be case-insensitive?
>
> Good catch.
> Funny how you can stare at something for ages...
>
> Using the same case would be sensible.
> I have also flagged this to the RFC Editor for [PCEP].
>
>> The rule you are updating from [PCEP] for PCReq has one of these:  
>> [<RRO>[<BANDWIDTH>]], which you are replacing with [<RRO>].
>> Is that intentional?
>
> Hmmm.
> Looks like PCEP gor updated since this I-D went through the working  
> group.
>
> Yes, we should update this I-D in line with the latest (final?)  
> version of PCEP).
>
> Thanks again.
> Adrian
>

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art