Re: [CCAMP] Question about partial SRLG collection flags

[Julien Meuric <[e-mail]>]

Hi Oscar.

For the encoding, I do not have yet a strong opinion about a generic 
filed vs. a per sub-object, but I feel that you will not avoid a 
dedicated I-D to enable a generic discussion about the mechanism at 
large. Progressing this discussion would help defining:
1- if a generic mechanism is interesting,
2- if per sub-object encoding is the way to go (assuming that a 
sub-network would actually update those flags, I agree that one must 
remain capable of associating the information to the corresponding 
sub-objects).
The answer to the latter would allow to know the impact on the SRLG 
collection I-D.

My 2 cents,

Julien


Le 04/07/2013 11:23, Oscar González de Dios a écrit :
> Dear CCAMP WG chairs and CCAMPrs,
>
> In the last IETF meeting we presented  RSVP-TE Extensions for 
> Collecting SRLG Information 
> ( draft-ietf-ccamp-rsvp-te-srlg-collect-02). This draft is about 
> collecting SRLG information in the RRO. We included a couple of flags 
> in the new SRLG sub-object, one to indicate if the SRLG-list contained 
> in the RRO sub-object has been edited in some way by a node 
> during signaling in accordance with that node's policy ,and another 
> one to indicate if the hat the SRLG-list contained in this RRO 
> sub-object is known to be incomplete.
>        After presenting , Lou mentioned that he partial SRLG-list 
> flags needs to be separated into an individual draft if it is a 
> generic function. We have been discussing this point and have some 
> doubts that we would like to share with the WG. First, the edited 
> flag/partial flag could potentially apply to any collected sub-object, 
> and thus can be considered generic. There are at least two drafts now 
> (the SRLG collection and the TE metric recording) where this 
> functionality is useful. However, if we want to make the flags 
> generic,  there are several issues: the RRO subjects are TLVs, and 
> each subobject is  defined independently. Thus, there is no common RRO 
> sub object header where the generic flags could fit. Another potential 
> problem is that all RRO TLVs defined so far have an 8-bit flags field; 
> if we want to go for something consistent, this will probably have to 
> expand at some point. In addition, there isn't a consistent place for 
> the flags to go (e.g. the IPv4/6 address objects put them at the end 
> of the TLV, whereas the others have them towards the beginning.
>
>       We would like to know your opinion on the matter, so we can take 
> the decision of keeping the flags in the SRLG collection draft, and 
> that if other drafts use the same flags they define them again for 
> their RRO sub objects, or going for a draft to define this flags, but 
> here we have the mentioned doubts on the approach.
>
> Best Regards,
>
> Oscar on behalf of draft-ietf-ccamp-rsvp-te-srlg-collect authors.
>
>
>
> ------------------------------------------------------------------------
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede 
> consultar nuestra política de envío y recepción de correo electrónico 
> en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send 
> and receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>
>
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp