Re: [CCAMP] Question about partial SRLG collection flags

Julien Meuric <> Fri, 12 July 2013 08:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41A1421F9D34 for <>; Fri, 12 Jul 2013 01:28:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.099
X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hE+eQkg-zW04 for <>; Fri, 12 Jul 2013 01:28:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AAC3321F9D4C for <>; Fri, 12 Jul 2013 01:28:09 -0700 (PDT)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id C20DCA440E1; Fri, 12 Jul 2013 10:29:51 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTP id B7C58A440DE; Fri, 12 Jul 2013 10:29:51 +0200 (CEST)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Jul 2013 10:28:07 +0200
Received: from [] ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Jul 2013 10:28:07 +0200
Message-ID: <>
Date: Fri, 12 Jul 2013 10:28:06 +0200
From: Julien Meuric <>
Organization: Orange
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: Oscar González de Dios <>
References: <7CFF94B047D8864CB6268315034E35DE2F5F34CD@EX10-MB2-MAD.hi.inet>
In-Reply-To: <7CFF94B047D8864CB6268315034E35DE2F5F34CD@EX10-MB2-MAD.hi.inet>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 12 Jul 2013 08:28:07.0258 (UTC) FILETIME=[BC4E63A0:01CE7ED9]
Cc: CCAMP <>
Subject: Re: [CCAMP] Question about partial SRLG collection flags
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Jul 2013 08:28:22 -0000

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 
The answer to the latter would allow to know the impact on the SRLG 
collection I-D.

My 2 cents,


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:
> _______________________________________________
> CCAMP mailing list