Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

"Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com> Mon, 12 January 2015 10:44 UTC

Return-Path: <wim.henderickx@alcatel-lucent.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E67D1A8ABD; Mon, 12 Jan 2015 02:44:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.61
X-Spam-Level:
X-Spam-Status: No, score=-4.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BEEF=2.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw4xrKsFEFJg; Mon, 12 Jan 2015 02:44:39 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1241B1A0191; Mon, 12 Jan 2015 02:44:39 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id F181283159E1B; Mon, 12 Jan 2015 10:44:34 +0000 (GMT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t0CAiWZk011767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Jan 2015 11:44:32 +0100
Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.219]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 12 Jan 2015 11:44:31 +0100
From: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>
To: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>, Rob Shakir <rjs@rob.sh>
Thread-Topic: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions
Thread-Index: AQHQLj+19rH0/A1Xy0ObHnHUPdPr+5y8G+CAgAARysCAAB57gA==
Date: Mon, 12 Jan 2015 10:44:31 +0000
Message-ID: <D0D9633B.11A80B%wim.henderickx@alcatel-lucent.com>
References: <D0CF6C5B.1B6DD%psarkar@juniper.net> <F3ADE4747C9E124B89F0ED2180CC814F4EEA26EF@xmb-aln-x02.cisco.com> <D0D00E58.1B720%psarkar@juniper.net> <F3ADE4747C9E124B89F0ED2180CC814F4EEA29A2@xmb-aln-x02.cisco.com> <D0D02765.1B76C%psarkar@juniper.net> <F3ADE4747C9E124B89F0ED2180CC814F4EEA2A4F@xmb-aln-x02.cisco.com> <BY1PR0501MB13812B36C2020C3AC3072641D5580@BY1PR0501MB1381.namprd05.prod.outlook.com> <F3ADE4747C9E124B89F0ED2180CC814F4EEA4F1A@xmb-aln-x02.cisco.com> <28823_1420641858_54AD4642_28823_8441_1_9E32478DFA9976438E7A22F69B08FF920C765C15@OPEXCLILM34.corporate.adroot.infra.ftgroup> <1868F3A4-A4E2-4504-A749-582305FA31B4@rob.sh> <18651_1421050415_54B3822F_18651_14831_1_9E32478DFA9976438E7A22F69B08FF920C76D265@OPEXCLILM34.corporate.adroot.infra.ftgroup> <53C29892C857584299CBF5D05346208A0EB01975@PEXCVZYM11.corporate.adroot.infra.ftgroup> <21149_1421052896_54B38BE0_21149_1085_1_86923dca-49c3-4745-881c-116ec27cb9f2@OPEXCLILH02.corporate.adroot.infra.ftgroup>
In-Reply-To: <21149_1421052896_54B38BE0_21149_1085_1_86923dca-49c3-4745-881c-116ec27cb9f2@OPEXCLILH02.corporate.adroot.infra.ftgroup>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.7.141117
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9C99534823F1234E836E76B0624E198B@exchange.lucent.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/ggbo5MFJQZcVeuox7aqjMvcw9fg>
Cc: "ospf@ietf.org" <ospf@ietf.org>, "spring@ietf.org" <spring@ietf.org>, "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" <draft-ietf-ospf-segment-routing-extensions@tools.ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>, "draft-ietf-isis-segment-routing-extensions@tools.ietf.org" <draft-ietf-isis-segment-routing-extensions@tools.ietf.org>
Subject: Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jan 2015 10:44:47 -0000

How many hops do we want to support in these scenario’s realistically?
This might help in determining the options

On 12/01/15 09:54, "stephane.litkowski@orange.com"
<stephane.litkowski@orange.com> wrote:

>Hi Bruno,
>
>Using TTL may work or not. Backup path does not mean that you will
>defacto have more hops. Metric of backup path could be higher but number
>of hops equal or smaller.
>
>I created a new thread on SPRING WG list to discuss the different options.
>
>Thanks !
>
>-----Original Message-----
>From: DECRAENE Bruno IMT/OLN
>Sent: Monday, January 12, 2015 09:49
>To: LITKOWSKI Stephane SCE/IBNF; Rob Shakir
>Cc: isis-wg@ietf.org;
>draft-ietf-ospf-segment-routing-extensions@tools.ietf.org; ospf@ietf.org;
>draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>Subject: RE: [OSPF] [Isis-wg] Mail regarding
>draft-ietf-ospf-segment-routing-extensions
>
>Hi,
>
>2 cents inlined
>
>> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of >
>> stephane.litkowski@orange.com
>> 
>> Hi,
>> 
>> After discussing a lot with Les offline, we almost found an agreement
>> on the understanding of this use case and possible relationship with
>> unprotected SIDs.
>> Use case :
>> 	Creation of a SR TE tunnel which is unprotected. Protection may be
>> provided end to end using for example two disjoint paths.
>> 	Controller based or ingress based tunnel setup.
>> 
>> It seems clear now that using ONLY unprotected SIDs does not solve the
>> issue as when a link fails, convergence will happen, and nodes that
>> are near the failure may reroute a NodeSID Algo 0 used within the TE
>> stack before Ingress or controller recomputes the new path fitting
>> constraints. So there may be transient situations where the path does
>>not fit constraints anymore.
>> Based on this, introducing "NON PROTECTED" NodeSID does not help in
>> solving this transient situation.
>> 
>> Now, as I explained, IMO, it's possible to introduce end to end OAM on
>> top on the SRTE to bring the LSP down as soon as there s something
>> wrong on the path. A Holddown timer can be used to keep LSP down until
>> convergence happens at Ingress or Controller. But introducing such OAM
>> and holddown and coupled with relations with IGP may also be complex
>> and there is a chance that it does not solve the issue. In case of
>> protected NodeSID used, OAM will not work, because switchover time
>> will be too small. Using OAM , defacto requires path with no protection.
>> So unprotected SID+OAM may solve the use at the price of some
>> complexity and possibly not solving 100% of the cases.
>> 
>> To conclude :
>> We need to solve this use case and we need to find another elegant,
>> simple and scalable solution for this.
>> 
>> Possible existing solutions :
>> - Use Adj-SID only => does not sounds good as there will be an impact
>> of stack depth => Path compression necessary
>> - Use binding TLV and create some new Node-SID corresponding to a set
>> of Adj-SID => This introduces more states within the network (how many
>> ?)
>> - Anything else ?
>
>Combining Adj-SID and Node-SID with a very restricted TTL (to expire on
>the backup path) may be able to avoid IGP rerouting of this LSP.
>
>/Bruno
>
> 
>> Best regards,
>> 
>> Stephane
>> 
>> 
>> -----Original Message-----
>> From: Rob Shakir [mailto:rjs@rob.sh]
>> Sent: Thursday, January 08, 2015 10:52
>> To: LITKOWSKI Stephane SCE/IBNF
>> Cc: Les Ginsberg (ginsberg); Shraddha Hegde; Pushpasis Sarkar; Peter
>> Psenak (ppsenak);
>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org; Hannes
>> Gredler; ospf@ietf.org; isis-wg@ietf.org
>> Subject: Re: [Isis-wg] [OSPF] Mail regarding
>> draft-ietf-ospf-segment-routing- extensions
>> 
>> Stephane,
>> 
>> If we think about the “MUST NOT be protected” case that you mention.
>> Let’s assume that we have a service that is performance sensitive,
>> such that we want to take a particular path through the network - and
>> that we use Node- SIDs like you say.
>> 
>> If we assume that the requirement is for A-B-C-D-E path below. The
>> node SID for E points via C-D-E and hence is used for stack
>> compression like you
>> say:
>> 
>>       A -- B -- C -- D -- E
>>                 |        /
>>                 --- Q ---
>> 
>> In your envisaged behaviour, C does not protect the Node-SID for E. In
>> the case of the C-D link failure, then the “preferred” behaviour is
>> that C now drops traffic towards this destination. However, C does not
>> remove the FIB entry for the Node-SID for E, it’s actually just now
>> known via Q. At this point, A can forward with exactly the same stack,
>> and the packet takes a new A-B- C-Q-E path, which is non-conformant
>> with the performance requirement of the service.
>> 
>> In terms of what C does with its FIB, does it simply not use C-Q-E
>> during the failure, but post-reconvergence use it anyway? If so, why
>> not use C-Q-E during the failure - because the service is always going
>> to non-conformant to the performance requirement?
>> 
>> With an Adj-SID, it makes sense, because essentially unless that
>> adjacency is available, then there is no alternate path for the SID
>> that will be taken - so traffic never hits a non-conformant path.
>> 
>> Practically, if I can’t tell a customer that the path taken will
>> definitely be A-B- C-D-E, and it may rather go via C-Q-E at some point
>> following convergence [until the head-end calculates that such a
>> change had happened - either a link outage, or a metric change - and
>> stops using the label stack], then there’s little problem of having the
>>traffic go via C-Q-E during protection.
>> 
>> For the disjoint case, the consideration that one has to make is:
>> 	* are alternative SPF paths for a particular Node-SID actually still
>> conformant with the disjointness requirement? How many simultaneous
>> failures does one require to violate constraints. For example, in a
>> dual-plane core network, then if the requirement is disjointness at
>> the IP level, then we may need to lose connectivity entirely within
>> the plane before it is preferable to “hop” to another plane. In this
>> case, using an alternative SPF path for the Node-SID is actually not a
>>problem for disjointness.
>> 	* does the application prefer losing an entire path to having some
>> risk of the services being shared fate until the re-optimisation?
>> 
>> From the work that we’ve looked at thus far, I have not yet seen a
>> case where I absolutely MUST NOT use an alternate shortest path for a
>> Node-SID and hence don’t require protection at a practical level.
>> 
>> Stack depth is definitely going to be something that we need to
>> consider - to me, where we have centralised controller - actions such
>> as dynamically created forwarding-adjacency LSPs which allow
>> “expansion” of one segment into a set of segments within the path are
>> attractive as a solution where one needs to have explicit routing of
>>traffic for TE purposes.
>> 
>> Does this make sense, or do you see the use case that we’re addressing
>> here differently?
>> 
>> Cheers,
>> r.
>> 
>> 
>> > On 7 Jan 2015, at 09:44, stephane.litkowski@orange.com wrote:
>> >
>> > Hi,
>> >
>> > I'm coming into this long thread and I tried to read all the
>> > exchange but I may be missed some lines :)
>> >
>> > But here is my opinion on this subject.
>> > I think the point from Shradda is valuable in case of Traffic
>> > Engineering with
>> Segment Routing, especially with a central controller.
>> >
>> > Today in TE networks, we are selling some disjoints paths to
>> > customer that
>> MUST NOT be protected (SDH like services). It would be good to
>> reproduce the same thing with SR-TE.
>> >
>> > Now, current encoding permits to advertise that a specific Adj-SID
>> > is
>> protected or not (as already mentioned, this does not say that a
>> protection really exists ..., in case of LFA protection , there may be
>> no FRR path for this adj-SID despite of the protection flag set).
>> > We pretty know that it would not be possible in all case to use only
>> > Adj-SID
>> for a TE tunnel (due to label stack depth), so we need to introduce
>> stack compression using SPT segments and node-SID.
>> > So to reply on Rob's comment, on RSVP-TE tunnels with looses hops
>> > that
>> does not request protection : yes for RSVP, it does not make sense to
>> me, but for SR, due to stack compression, it will be needed.
>> >
>> > If we look at a network, where TE is managed by a central
>> > controller, how
>> the controller can ensure that the node-SID used is protected or not
>> (as for Adj-SID, I mean protection requested, not protection
>> installed). I see two ways :
>> > 	* Use two SIDs attached to the same prefix and add a flag to
>> > prevent
>> automatically all nodes to compute a protection for one of the SID.
>> The flag does not really force nodes to compute a protection. Each
>> node will still require local configuration for protection, but the
>> flag will permit to exclude some prefixes for protection (overriding
>>local policy).
>> >
>> > 	* Use two prefixes on each node , prefixes are marked with tags
>> (admin-tags) : "protection tag" and "non protection tag". Each router
>> is configured using LFA policies to not compute protection for
>> prefixes having "non protection tag" AND add knowledge to the
>> controller to use only "non protection tag" prefixes to compress non
>>protected path.
>> >
>> >
>> > Best Regards,
>> >
>> > Stephane
>> >
>> > -----Original Message-----
>> > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Les
>> > Ginsberg (ginsberg)
>> > Sent: Monday, January 05, 2015 16:59
>> > To: Shraddha Hegde; Pushpasis Sarkar; Peter Psenak (ppsenak);
>> > draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>> > draft-ietf-isis-segment-routing-extensions@tools.ietf.org; Hannes
>> > Gredler
>> > Cc: ospf@ietf.org; isis-wg@ietf.org
>> > Subject: Re: [Isis-wg] [OSPF] Mail regarding
>> > draft-ietf-ospf-segment-routing-extensions
>> >
>> > Shraddha -
>> >
>> > As Jeff has already mentioned, the case you are concerned about can
>> > be handled using LFA selection strategies discussed in
>> > http://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/
>> > And it is a far better solution since it allows the traffic of
>> > interest to be
>> protected => less traffic interruption.
>> >
>> >   Les
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: Shraddha Hegde [mailto:shraddha@juniper.net]
>> > Sent: Monday, January 05, 2015 12:49 AM
>> > To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Peter Psenak
>> > (ppsenak); 
>> > draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>> > draft-ietf-isis-segment-routing-extensions@tools.ietf.org; Hannes
>> > Gredler
>> > Cc: ospf@ietf.org; isis-wg@ietf.org
>> > Subject: RE: [OSPF] [Isis-wg] Mail regarding
>> > draft-ietf-ospf-segment-routing-extensions
>> >
>> > Les,
>> >
>> > Pls consider a case when the post convergence path goes through a
>> different node and is well provisioned.
>> >
>> > --------G-------
>> > |                     |
>> > A----B----C----D
>> >        |       |
>> >          E----F
>> >
>> > When the link between B & C goes down, we don’t want to divert the
>> traffic via B-E-E-F-C because it is not well provisioned for the
>>service.
>> > The post convergence path is A-G-D which is well provisioned.
>> > In this case it makes sense to simply avoid protection for the
>> > service as the
>> nature of the service is such that it can be disconnected and
>> reconnected without impacting the end user of the service.
>> >
>> >
>> > The post convergence paths need to be provisioned at least for one
>> > failure
>> if that is not the case then the service will remain down Irrespective
>> of the technology used.
>> >
>> >
>> > Rgds
>> > Shraddha
>> >
>> > -----Original Message-----
>> > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
>> > Sent: Monday, January 05, 2015 12:07 PM
>> > To: Pushpasis Sarkar; Shraddha Hegde; Peter Psenak (ppsenak);
>> > draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>> > draft-ietf-isis-segment-routing-extensions@tools.ietf.org; Hannes
>> > Gredler
>> > Cc: ospf@ietf.org; isis-wg@ietf.org
>> > Subject: RE: [OSPF] [Isis-wg] Mail regarding
>> > draft-ietf-ospf-segment-routing-extensions
>> >
>> > Pushpasis -
>> >
>> > Inline.
>> >
>> > -----Original Message-----
>> > From: Pushpasis Sarkar [mailto:psarkar@juniper.net]
>> > Sent: Sunday, January 04, 2015 10:13 PM
>> > To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak (ppsenak);
>> > draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>> > draft-ietf-isis-segment-routing-extensions@tools.ietf.org; Hannes
>> > Gredler
>> > Cc: ospf@ietf.org; isis-wg@ietf.org
>> > Subject: Re: [OSPF] [Isis-wg] Mail regarding
>> > draft-ietf-ospf-segment-routing-extensions
>> >
>> > Hi Les,
>> >
>> >
>> > On 1/5/15, 11:23 AM, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
>> wrote:
>> >
>> >> Pushpasis -
>> >>
>> >> The key point is that the proposal does not have any lasting impact
>> >> on traffic flow. A simple topology should suffice to illustrate this.
>> >>
>> >>
>> >> A----B----C----D
>> >>         |       |
>> >>         E----F
>> >>
>> >> (All links have the same cost)
>> >>
>> >> Suppose we wish to have traffic entering at A flow along the path
>> >> A-B-C-D
>> >> - but if the link B---C fails we do NOT want traffic to take the
>> >> path B--E--F--C.
>> >>
>> >> You propose to have C advertise an address with two node-sids - one
>> >> which allows protection - call it C(P) - and one which does NOT
>> >> allow protection - call it C(NP).
>> > [Pushpasis] No. My proposal is for D to advertise two node sids, D1
>> > with NP
>> set to 0 and D2 with NP set to 1. Applications on that do not need B,
>> or C to protect the A-B-C-D path will use D2. B and C will not install
>> backup paths for D2. Other apps can use D1 as they are supposed to do
>> otherwise. Wether to protect D1 or not is a local decision of B and C.
>> > Hope I could clarify enough :)
>> >
>> > [Les:] Whether we talk about C or D doesn’t matter. As you point out
>> below the issue you are concerned with is the FIB update time on the
>> intermediate nodes relative to the recomputation on the ingress node.
>> >
>> >>
>> >> If the label stack specifies C(NP) - then while the link B--C is UP
>> >> everything works as desired (primary path to C(NP) on Node B is via
>> >> link B-C).
>> >> However, when the link B--C goes down, the network will reconverge
>> >> and in a modest amount of time the new primary path to C(NP) on
>> >> node B will be via link B-E.
>> > [Pushpasis] Yes agreed. But only applications on A will be injecting
>> > traffic
>> using D2. Once the B-C link-down event reaches router A will stop
>> injecting traffic using D2. A path re-compute will be triggered on A.
>> Yes I agree that if B converges D2 (not FRR) before A re-compute,
>> there is still chance that some small amount of traffic is sent over
>>A-B-E-F-C-D.
>> >
>> > [Les:] Well yes - the key point is that you cannot guarantee the
>> > timing of
>> when B (for example) will reconverge relative to when the ingress node
>> A decides to reroute/drop the D2 traffic. Given that B is closer to
>> the failure it is quite likely that B will respond more quickly than A
>> - and of course there are many other variables which could affect the
>> relative response time of A and B. So the sole benefit of what you
>> propose seems to be that in some cases you MIGHT not send as much
>>traffic to D2 via the undesired links.
>> >
>> > At this point I think you would do well to look at the existing
>> > solutions - as
>> well as Jeff's post on this thread which provides an excellent
>> framework for thinking about solutions. We do have ways of addressing
>> this problem and doing so far more robustly than what you are
>> proposing. The ROI for what you propose is quite low. For my part I
>> don’t think what you propose is a good idea.
>> >
>> >    Les
>> >
>> >>
>> >> The existence of C(NP) therefore only affects traffic flow during
>> >> the reconvergence period i.e. if we assume B did NOT install a
>> >> repair path for C(NP) traffic will be dropped only until a new
>> >> primary path is calculated. I don’t see the value in this.
>> >>
>> >> As a (somewhat dangerous) aside, the functionality you are looking
>> >> for is more akin to "not-via" as defined in RFC 6981 - though I am
>> >> quick to add that I am NOT proposing to pursue that. :-) But
>> >> reading that RFC might give you more insight into why simply
>> >> setting "don't protect" for a prefix isn't useful for the purpose
>>you have in mind.
>> >>
>> >>  Les
>> >>
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Pushpasis Sarkar [mailto:psarkar@juniper.net]
>> >> Sent: Sunday, January 04, 2015 8:34 PM
>> >> To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak
>> >> (ppsenak); 
>> >> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>> >> draft-ietf-isis-segment-routing-extensions@tools.ietf.org; Hannes
>> >> Gredler
>> >> Cc: ospf@ietf.org; isis-wg@ietf.org
>> >> Subject: Re: [OSPF] [Isis-wg] Mail regarding
>> >> draft-ietf-ospf-segment-routing-extensions
>> >>
>> >> Hi Les,
>> >>
>> >> Please find comments inline..
>> >>
>> >> Authors,
>> >>
>> >> Here is my proposal. Please let me know if this sounds reasonable or
>>not.
>> >>
>> >> - A new ŒNo-Potection-Required¹ or ŒNP¹ flag be added to the
>> >> Prefix-SID Sub-TLV/TLV. Setting this flag means none of the transit
>> >> routers should try to protect this node-segment.
>> >> - Let nodes advertise two node-sid-index each (per address-family),
>> >> one without and one with ŒNP¹ flag set. For node-sid advertised
>> >> with ŒNP¹ flag 0, routers same behave the same way as today. But
>> >> when they receive a node-sid with ŒNP¹ flag set, they avoid/skip
>> >> finding a backup for that segment.
>> >> - Finally ingress servers or TE-applications may use these
>> >> 'node-sids with NP-flag set¹ for use cases where it is better to
>> >> drop traffic on topology outages rather than diverting it to some
>> >> other paths. For such cases ingress router or TE-applications
>> >> should look for node-sids with ŒNP¹ flag set and not the regular
>> >> node-sids. For all other normal use cases(including L3VPN/6VPE etc)
>> >> traffic should be carried using node-sid without ŒNP‹flag set.
>> >>
>> >> Thanks and Regards,
>> >> -Pushpasis
>> >>
>> >> On 1/5/15, 3:37 AM, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
>> wrote:
>> >>
>> >>> Pushpasis -
>> >>>
>> >>> I don't agree.
>> >>>
>> >>> The use of one node-sid vs another has nothing whatever to do with
>> >>> the request Shraddha has made i.e. should we introduce a flag
>> >>> indicating whether a particular prefix should be protected or not.
>> >>> A node-sid only dictates what (intermediate) node traffic should
>> >>> be sent to - not what
>> >>> link(s) are used to reach that node.
>> >> [Pushpasis] This is not about which links to take. It is about
>> >> wether transit routers should try to protect the node-segment to
>> >> the this node-sid or not. I think this opens up a lot many number
>> >> of possibilities on the ingress router and TE controller-based
>>applications.
>> >>
>> >>>
>> >>> Adjacency-sids have a different semantic - they identify the link
>> >>> over which traffic is to be forwarded. Identifying an
>> >>> adjacency-sid as unprotected means traffic will NEVER flow over a
>>different link.
>> >>> There is no equivalent behavior w a node-sid - which is what this
>> >>> discussion has been about.
>> >> [Pushpasis] I am not trying to draw a parallel between this new
>> >> flag and the ŒB¹ flag in Adj-Sid SubTlv. Like said before
>> >>
>> >>>
>> >>>  Les
>> >>>
>> >>>
>> >>> -----Original Message-----
>> >>> From: Pushpasis Sarkar [mailto:psarkar@juniper.net]
>> >>> Sent: Sunday, January 04, 2015 8:51 AM
>> >>> To: Les Ginsberg (ginsberg); Shraddha Hegde; Peter Psenak
>> >>> (ppsenak); 
>> >>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>> >>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>> >>> Cc: ospf@ietf.org; isis-wg@ietf.org
>> >>> Subject: Re: [OSPF] [Isis-wg] Mail regarding
>> >>> draft-ietf-ospf-segment-routing-extensions
>> >>>
>> >>> Hi Les,
>> >>>
>> >>> I think the requirement Shraddha is referring is about the choice
>> >>> of exact node-sid to use while constructing the label-stack for a
>> >>> explicit-LSP on the ingress router, which will be typically done
>> >>> after running some CSPF on the SPRING topology. And not the IGP on
>> >>> ingress or transit routers.
>> >>>
>> >>> Thanks
>> >>> -Pushpasis
>> >>>
>> >>> On 1/3/15, 3:10 AM, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
>> wrote:
>> >>>
>> >>>> Shraddha -
>> >>>>
>> >>>> IGPs today do NOT perform constraint based SPFs - so I don't know
>> >>>> why you believe that the primary SPF will meet a set of
>> >>>> constraints that an LFA calculation will not. In fact , it is the
>> >>>> opposite which is true because implementations today do support
>> >>>> preferences in choosing LFAs based on various configured policy -
>> >>>> something which is NOT done for primary SPF.
>> >>>>
>> >>>> If you want a certain class of traffic to avoid a subset of the
>> >>>> links in the topology then you need to have a way of identifying
>> >>>> the links (NOT the node addresses) and a way of calculating a
>> >>>> path which only uses the links which meet the constraints of that
>> >>>> class of
>> service.
>> >>>> Identifying a particular prefix as protected or unprotected won't
>> >>>> achieve that.
>> >>>>
>> >>>>  Les
>> >>>>
>> >>>> -----Original Message-----
>> >>>> From: Shraddha Hegde [mailto:shraddha@juniper.net]
>> >>>> Sent: Friday, January 02, 2015 10:54 AM
>> >>>> To: Les Ginsberg (ginsberg); Peter Psenak (ppsenak);
>> >>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>> >>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>> >>>> Cc: ospf@ietf.org; isis-wg@ietf.org
>> >>>> Subject: RE: [Isis-wg] Mail regarding
>> >>>> draft-ietf-ospf-segment-routing-extensions
>> >>>>
>> >>>> Hi Les/Peter,
>> >>>>
>> >>>>     When reconvergence happens, the primary path will be
>> >>>> calculated based on all constriants.
>> >>>> This is not true with the protection path.Protection path is
>> >>>> calculated locally (LFA/RLFA)  and does not consider the
>> >>>> characteristics of the services running on that path.
>> >>>> It's easier for some services to pick the unprotected path when
>> >>>> the nature of the service is that it can be restarted  when there
>> >>>> is a disconnection.
>> >>>>
>> >>>> Rgds
>> >>>> Shraddha
>> >>>> -----Original Message-----
>> >>>> From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
>> >>>> Sent: Friday, January 02, 2015 10:06 PM
>> >>>> To: Peter Psenak (ppsenak); Shraddha Hegde;
>> >>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>> >>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>> >>>> Cc: ospf@ietf.org; isis-wg@ietf.org
>> >>>> Subject: RE: [Isis-wg] Mail regarding
>> >>>> draft-ietf-ospf-segment-routing-extensions
>> >>>>
>> >>>> Peter -
>> >>>>
>> >>>> The requirement Shraddha specified was to not allow a particular
>> >>>> class of service ("heavy bandwidth services" was the example
>> >>>> provided) to use certain links in the topology. My point is that
>> >>>> advertising a flag for a given prefix which says "do not
>> >>>> calculate a repair path for this prefix"
>> >>>> does not help achieve this. Once the network reconverges
>> >>>> following the failure of one of the links on which "heavy
>>bandwidth services"
>> >>>> is allowed/preferred it is quite likely that the new best path
>> >>>> will be over a link on which "heavy bandwidth services" is NOT
>> >>>> allowed/preferred. This will happen whether you have the new flag
>> >>>> or not - so the flag will have no lasting effect. It would only
>> >>>> affect traffic flow during the brief period during which the
>> >>>> network is reconverging.
>> >>>>
>> >>>> I think you and I are actually in agreement - I am simply sending
>> >>>> a stronger negative message - not only do I think the flag is not
>> >>>> useful
>> >>>> - I think it does not achieve the goal Shraddha has in mind.
>> >>>>
>> >>>>  Les
>> >>>>
>> >>>>
>> >>>> -----Original Message-----
>> >>>> From: Peter Psenak (ppsenak)
>> >>>> Sent: Friday, January 02, 2015 12:18 AM
>> >>>> To: Les Ginsberg (ginsberg); Shraddha Hegde;
>> >>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>> >>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>> >>>> Cc: ospf@ietf.org; isis-wg@ietf.org
>> >>>> Subject: Re: [Isis-wg] Mail regarding
>> >>>> draft-ietf-ospf-segment-routing-extensions
>> >>>>
>> >>>> Hi Les,
>> >>>>
>> >>>> I believe the idea is not to exclude any particular link, it's
>> >>>> actually much simpler - do not calculate backup for the prefix if
>> >>>> the flag is set.
>> >>>>
>> >>>> I'm still not quite sure how useful above is, but technically it
>> >>>> is possible.
>> >>>>
>> >>>> thanks,
>> >>>> Peter
>> >>>>
>> >>>> On 12/30/14 17:22 , Les Ginsberg (ginsberg) wrote:
>> >>>>> Shraddha -
>> >>>>>
>> >>>>> When performing a best path calculation whether a given link is
>> >>>>> in the set of best paths (to be protectedED) or not (could be
>> >>>>> used as a protectING path) is a function of the topology - not
>>the link.
>> >>>>> If there is a topology change it is quite likely that a given
>> >>>>> link will change from being a protectED link to being a
>> >>>>> protectING link (or vice versa).
>> >>>>> So what you propose regarding node-SIDs would not work.
>> >>>>>
>> >>>>> In the use case you mention below if you don't want a certain
>> >>>>> class of traffic to flow on a given link it requires a link
>> >>>>> attribute which is persistent across topology changes. There are
>> >>>>> ways to do that - using Adj-SIDs is one of them. But using
>> >>>>> node-SIDs in the way you propose is NOT.
>> >>>>>
>> >>>>>    Les
>> >>>>>
>> >>>>> -----Original Message-----
>> >>>>> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Shraddha
>> >>>>> Hegde
>> >>>>> Sent: Monday, December 29, 2014 10:12 PM
>> >>>>> To: Peter Psenak (ppsenak);
>> >>>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>> >>>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>> >>>>> Cc: ospf@ietf.org; isis-wg@ietf.org
>> >>>>> Subject: Re: [OSPF] [Isis-wg] Mail regarding
>> >>>>> draft-ietf-ospf-segment-routing-extensions
>> >>>>>
>> >>>>> Peter,
>> >>>>>
>> >>>>>> The requirement here is to get an un-protected path for
>> >>>>>> services which do not want to divert the traffic on protected
>>path in any case.
>> >>>>>
>> >>>>>> can you give an example of such a service and a reasoning why
>> >>>>>> such service would want to avoid local protection along the path?
>> >>>>>
>> >>>>> Heavy bandwidth services are potential candidates.  The network
>> >>>>> is well planned and well provisioned for primary path but same
>> >>>>> is not true for backup paths.
>> >>>>> Diverting heavy bandwidth services along protection path can
>> >>>>> disrupt the other services on that path, they are better-off
>> >>>>> un-protected so that an event in the network Would result in
>> >>>>> disconnection and a retry for such services.
>> >>>>>
>> >>>>> Rgds
>> >>>>> Shraddha
>> >>>>>
>> >>>>> -----Original Message-----
>> >>>>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>> >>>>> Sent: Monday, December 29, 2014 4:35 PM
>> >>>>> To: Shraddha Hegde;
>> >>>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>> >>>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>> >>>>> Cc: ospf@ietf.org; isis-wg@ietf.org
>> >>>>> Subject: Re: [Isis-wg] Mail regarding
>> >>>>> draft-ietf-ospf-segment-routing-extensions
>> >>>>>
>> >>>>> Shraddha,
>> >>>>>
>> >>>>> On 12/29/14 10:06 , Shraddha Hegde wrote:
>> >>>>>> Peter,
>> >>>>>>
>> >>>>>> The requirement here is to get an un-protected path for
>> >>>>>> services which do not want to divert the traffic on protected
>>path in any case.
>> >>>>>
>> >>>>> can you give an example of such a service and a reasoning why
>> >>>>> such service would want to avoid local protection along the path?
>> >>>>>
>> >>>>> thanks,
>> >>>>> Peter
>> >>>>>
>> >>>>>> So when the originator of node-sid signals un-protected path
>> >>>>>> requirement, there is always an unprotected path.
>> >>>>>>
>> >>>>>> Regarding the protected path, it is the default behavior as it
>> >>>>>> exists today. You get protection if it's available otherwise
>> >>>>>> you don't get protection.
>> >>>>>>
>> >>>>>> In fact, you can have the new flag to say "NP flag" meaning
>> >>>>>> non-protected flag which can be set for the unprotected path.
>> >>>>>> By default it remains off and gives the behavior as it exists
>>today.
>> >>>>>>
>> >>>>>>
>> >>>>>> Rgds
>> >>>>>> Shraddha
>> >>>>>>
>> >>>>>> -----Original Message-----
>> >>>>>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>> >>>>>> Sent: Monday, December 29, 2014 2:26 PM
>> >>>>>> To: Shraddha Hegde;
>> >>>>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>> >>>>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>> >>>>>> Cc: ospf@ietf.org; isis-wg@ietf.org
>> >>>>>> Subject: Re: [Isis-wg] Mail regarding
>> >>>>>> draft-ietf-ospf-segment-routing-extensions
>> >>>>>>
>> >>>>>> Shraddha,
>> >>>>>>
>> >>>>>> I do not see how an originator of the node-sid can mandate a
>> >>>>>> protection for the prefix on other routers. What if there is no
>> >>>>>> backup available on a certain node along the path?
>> >>>>>>
>> >>>>>> The parallel with the B-flag in adj-sids is not right - in case
>> >>>>>> of adj-sid the originator has the knowledge about the local
>> >>>>>> adjacency protection and as such can signal it it it's LSA.
>> >>>>>>
>> >>>>>> thanks,
>> >>>>>> Peter
>> >>>>>>
>> >>>>>>
>> >>>>>> On 12/29/14 09:47 , Shraddha Hegde wrote:
>> >>>>>>> Peter,
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Pls see inline.
>> >>>>>>>
>> >>>>>>> Rgds
>> >>>>>>> Shraddha
>> >>>>>>>
>> >>>>>>> -----Original Message-----
>> >>>>>>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>> >>>>>>> Sent: Monday, December 29, 2014 2:02 PM
>> >>>>>>> To: Shraddha Hegde;
>> >>>>>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>> >>>>>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>> >>>>>>> Cc: ospf@ietf.org; isis-wg@ietf.org
>> >>>>>>> Subject: Re: [Isis-wg] Mail regarding
>> >>>>>>> draft-ietf-ospf-segment-routing-extensions
>> >>>>>>>
>> >>>>>>> Shraddha,
>> >>>>>>>
>> >>>>>>> I do not see how an originator can set any flag regarding the
>> >>>>>>> protection of the locally attached prefix.
>> >>>>>>> <Shraddha> The originator advertises 2 node-sids. One with p
>> >>>>>>> flag set and the other without the p-flag set.
>> >>>>>>>
>> >>>>>>>    It's all the routers on the path towards such prefix that
>> >>>>>>> need to deal with the protection.
>> >>>>>>> <Shraddha> The receiving nodes will download protected path
>> >>>>>>> for the node-sid with p-flag set and download Unprotected path
>> >>>>>>> for the node-sid with p-flag unset.
>> >>>>>>>
>> >>>>>>> Signaling anything from the originator seems useless.
>> >>>>>>> <Shraddha>  For node-sids it's the others who need to build
>> >>>>>>> the forwarding plane but it's only the originator who can
>>signal which of
>> >>>>>>>                           Sid need to be built with protection
>> >>>>>>> and which not. Other routers on the path cannot signal this
>> >>>>>>> information.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>>
>> >>>>>>> With this you have two paths for the node. One is protected
>> >>>>>>> and the other is unprotected. This meets the requirement of
>> >>>>>>> having an un-protected path.
>> >>>>>>>
>> >>>>>>> It's very much in parallel to B-flag in adj-sids. It is
>> >>>>>>> similar to advertising multiple adj-sids one with B-flag on
>> >>>>>>> and other with b-flag off , to get protected and unprotected
>>Adj-sids.
>> >>>>>>>
>> >>>>>>> thanks,
>> >>>>>>> Peter
>> >>>>>>>
>> >>>>>>> On 12/29/14 09:26 , Shraddha Hegde wrote:
>> >>>>>>>> Yes.You are right.
>> >>>>>>>>
>> >>>>>>>> Lets say a prefix sid has a flag "p flag". If this is on it
>> >>>>>>>> means build a path and provide protection.
>> >>>>>>>> If this is off it means build a path with no protection.
>> >>>>>>>> The receivers of the prefix-sid will build forwarding plane
>> >>>>>>>> based on this flag.
>> >>>>>>>>
>> >>>>>>>> The applications building the paths will either use
>> >>>>>>>> prefix-sids with p flag on or off based on the need of the
>>service.
>> >>>>>>>> Rgds
>> >>>>>>>> Shraddha
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> -----Original Message-----
>> >>>>>>>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>> >>>>>>>> Sent: Monday, December 29, 2014 1:49 PM
>> >>>>>>>> To: Shraddha Hegde;
>> >>>>>>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>> >>>>>>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>> >>>>>>>> Cc: ospf@ietf.org; isis-wg@ietf.org
>> >>>>>>>> Subject: Re: [Isis-wg] Mail regarding 
>> >>>>>>>> draft-ietf-ospf-segment-routing-extensions
>> >>>>>>>>
>> >>>>>>>> Shraddha,
>> >>>>>>>>
>> >>>>>>>> the problem is that the node that is advertising the node-sid 
>> >>>>>>>> can not advertise any data regarding the protection of such 
>> >>>>>>>> prefix, because the prefix is locally attached.
>> >>>>>>>>
>> >>>>>>>> thanks,
>> >>>>>>>> Peter
>> >>>>>>>>
>> >>>>>>>> On 12/29/14 09:15 , Shraddha Hegde wrote:
>> >>>>>>>>> Peter,
>> >>>>>>>>>
>> >>>>>>>>> If there is a service which has to use un-protected path and 
>> >>>>>>>>> while  building such a path if the node-sids Need to be used 
>> >>>>>>>>> (one reason  could be label stack compression) , then there 
>> >>>>>>>>> has to be unprotected node-sid that this service can make 
>> >>>>>>>>> use
>> of.
>> >>>>>>>>>
>> >>>>>>>>> Prefix -sids could also be used to represent different 
>> >>>>>>>>> service endpoints which makes it even more relevant to have 
>> >>>>>>>>> A means
>> of
>> >>>>>>>>> representing  unprotected paths.
>> >>>>>>>>>
>> >>>>>>>>> Would be good to hear from others on this, especially 
>>operators.
>> >>>>>>>>>
>> >>>>>>>>> Rgds
>> >>>>>>>>> Shraddha
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> -----Original Message-----
>> >>>>>>>>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>> >>>>>>>>> Sent: Monday, December 29, 2014 1:35 PM
>> >>>>>>>>> To: Shraddha Hegde;
>> >>>>>>>>> draft-ietf-ospf-segment-routing-extensions@tools.ietf.org;
>> >>>>>>>>> draft-ietf-isis-segment-routing-extensions@tools.ietf.org
>> >>>>>>>>> Cc: ospf@ietf.org; isis-wg@ietf.org
>> >>>>>>>>> Subject: Re: [Isis-wg] Mail regarding 
>> >>>>>>>>> draft-ietf-ospf-segment-routing-extensions
>> >>>>>>>>>
>> >>>>>>>>> Shraddha,
>> >>>>>>>>>
>> >>>>>>>>> node-SID is advertised by the router for the prefix that is 
>> >>>>>>>>> directly attached to it. Protection for such local prefix 
>> >>>>>>>>> does not mean much.
>> >>>>>>>>>
>> >>>>>>>>> thanks,
>> >>>>>>>>> Peter
>> >>>>>>>>>
>> >>>>>>>>> On 12/24/14 11:57 , Shraddha Hegde wrote:
>> >>>>>>>>>> Authors,
>> >>>>>>>>>> We have a "backup flag" in adjacency sid to indicate 
>> >>>>>>>>>> whether the label is protected or not.
>> >>>>>>>>>> Similarly. I think we need a flag in prefix-sid as well to 
>> >>>>>>>>>> indicate whether the node-sid is to be protected or not.
>> >>>>>>>>>> Any thoughts on this?
>> >>>>>>>>>> Rgds
>> >>>>>>>>>> Shraddha
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> _______________________________________________
>> >>>>>>>>>> Isis-wg mailing list
>> >>>>>>>>>> Isis-wg@ietf.org
>> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/isis-wg
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> .
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>> .
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>> .
>> >>>>>>>
>> >>>>>>
>> >>>>>> .
>> >>>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> OSPF mailing list
>> >>>>> OSPF@ietf.org
>> >>>>> https://www.ietf.org/mailman/listinfo/ospf
>> >>>>> .
>> >>>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> OSPF mailing list
>> >>>> OSPF@ietf.org
>> >>>> https://www.ietf.org/mailman/listinfo/ospf
>> >>>
>> >>
>> >
>> > _______________________________________________
>> > Isis-wg mailing list
>> > Isis-wg@ietf.org
>> > https://www.ietf.org/mailman/listinfo/isis-wg
>> >
>> >
>> __________________________________________________________
>> ____________
>> > ___________________________________________________
>> >
>> > Ce message et ses pieces jointes peuvent contenir des informations 
>> > confidentielles ou privilegiees et ne doivent donc pas etre 
>> > diffuses, exploites ou copies sans autorisation. Si vous avez recu 
>> > ce message par erreur, veuillez le signaler a l'expediteur et le 
>> > detruire ainsi que les
>> pieces jointes. Les messages electroniques etant susceptibles 
>> d'alteration, Orange decline toute responsabilite si ce message a ete 
>> altere, deforme ou falsifie. Merci.
>> >
>> > This message and its attachments may contain confidential or 
>> > privileged information that may be protected by law; they should not 
>> > be
>> distributed, used or copied without authorisation.
>> > If you have received this email in error, please notify the sender 
>> > and delete
>> this message and its attachments.
>> > As emails may be altered, Orange is not liable for messages that 
>> > have been
>> modified, changed or falsified.
>> > Thank you.
>> >
>> > _______________________________________________
>> > Isis-wg mailing list
>> > Isis-wg@ietf.org
>> > https://www.ietf.org/mailman/listinfo/isis-wg
>> 
>> 
>> __________________________________________________________
>> __________________________________________________________
>> _____
>> 
>> Ce message et ses pieces jointes peuvent contenir des informations 
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
>> exploites ou copies sans autorisation. Si vous avez recu ce message 
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi 
>> que les pieces jointes. Les messages electroniques etant susceptibles 
>> d'alteration, Orange decline toute responsabilite si ce message a ete 
>>altere, deforme ou falsifie. Merci.
>> 
>> This message and its attachments may contain confidential or 
>> privileged information that may be protected by law; they should not 
>> be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and 
>> delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have 
>> been modified, changed or falsified.
>> Thank you.
>> 
>> _______________________________________________
>> OSPF mailing list
>> OSPF@ietf.org
>> https://www.ietf.org/mailman/listinfo/ospf
>
>__________________________________________________________________________
>_______________________________________________
>
>Ce message et ses pieces jointes peuvent contenir des informations 
>confidentielles ou privilegiees et ne doivent donc
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
>recu ce message par erreur, veuillez le signaler
>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
>electroniques etant susceptibles d'alteration,
>Orange decline toute responsabilite si ce message a ete altere, deforme 
>ou falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged 
>information that may be protected by law;
>they should not be distributed, used or copied without authorisation.
>If you have received this email in error, please notify the sender and 
>delete this message and its attachments.
>As emails may be altered, Orange is not liable for messages that have 
>been modified, changed or falsified.
>Thank you.
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www.ietf.org/mailman/listinfo/ospf