Subject: [CCAMP] Question about partial SRLG collection flags

From: Oscar González de Dios <[email-masked]>
Date: Thu, 04 Jul 2013 09:23:04 +0000

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

---

From: Julien Meuric <[email-masked]>
Date: Fri, 12 Jul 2013 10:28:06 +0200

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 :
> 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,
>
> ------------------------------------------------------------------------
>
> 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:
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp