Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

[<[e-mail]>]

Hi Les,

Many thanks for the text proposal.
I agree on most of the proposal expect :
" When
   the procedures defined in [SR-MPLS] for mapping global SIDs to
   outgoing labels are followed the advertising node is determined to be
   incapable of supporting all global SIDs."

The statement is not true, as if the advertising node has a global SID with PHP enabled or explicit-null, there is no need of SRGB for installing the label mapping.
I would rather propose a slight change to align with [SR-MPLS] wording :
" When
   the procedures defined in [SR-MPLS] for mapping global SIDs to
   outgoing labels are followed the advertising node is determined to be
   incapable of supporting MPLS operations for global SIDs."

Best regards,

Stephane

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[e-mail]] 
Sent: Tuesday, February 02, 2016 01:22
To: Stefano Previdi (sprevidi); LITKOWSKI Stephane SCE/OINIS
Cc: DECRAENE Bruno IMT/OLN; [e-mail]; Uma Chunduri; Henderickx, Wim (Wim)
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Now that draft-ietf-spring-segment-routing-mpls-03.txt is available, here is proposed text for draft-ginsberg-spring-conflict-resolution Section 2 which reflects the conclusions of this thread regarding handling of SRGB inconsistency:

"For the set of ranges to be usable the ranges MUST be disjoint.
   Sender behavior is defined in various SR protocol drafts such as [SR-
   IS-IS] which specify that senders MUST NOT advertise overlapping
   ranges.

   Receivers of SRGB ranges MUST validate the SRGB ranges advertised by
   other nodes.  If overlapping ranges are detected receivers MUST
   ignore all advertised SRGB ranges from that node.  Operationally the
   node is treated as though it did not advertise any SRGB ranges.  When
   the procedures defined in [SR-MPLS] for mapping global SIDs to
   outgoing labels are followed the advertising node is determined to be
   incapable of supporting all global SIDs.

   Note that utilization of local SIDs (e.g. adjacency SIDs) advertised
   by a node is not affected by the state of the advertised SRGB."


    Les


> -----Original Message-----
> From: spring [mailto:[e-mail]] On Behalf Of Les Ginsberg
> (ginsberg)
> Sent: Wednesday, January 20, 2016 6:04 AM
> To: Stefano Previdi (sprevidi); Stephane Litkowski
> Cc: [e-mail]; [e-mail]; Uma Chunduri;
> Henderickx, Wim (Wim)
> Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> INCONSISTENCY
> 
> Stefano -
> 
> Thanx for the proposal - it makes sense to me.
> 
> The handling of overlapping SRGB then reduces to following the procedures
> defined in the to be updated sr-mpls draft for the case where a SID cannot
> be mapped to the (set of) SRGB ranges advertised by the nexthop. This will
> make clear that the PHP case is unaffected by overlapping SRGB ranges.
> 
> Once a proposal for the revised sr-mpls draft is available I will propose new
> text for draft-ginsberg-spring-conflict-resolution. This should address the
> concerns raised by Bruno and Stephane.
> 
>    Les
> 
> 
> > -----Original Message-----
> > From: Stefano Previdi (sprevidi)
> > Sent: Wednesday, January 20, 2016 5:52 AM
> > To: Stephane Litkowski; Les Ginsberg (ginsberg)
> > Cc: Uma Chunduri; [e-mail]; [e-mail];
> > Henderickx, Wim (Wim)
> > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> > INCONSISTENCY
> >
> > Hi Stephane,
> >
> > I agree with you.
> >
> > I also noticed that in draft-ietf-spring-segment-routing-mpls we
> > should have
> > (probably) a better description on how to use SRGB and indexes.
> >
> > I propose to update draft-ietf-spring-segment-routing-mpls so that the
> > conflict-resolution draft can point to it when referring to
> > SRGB/index procedures.
> >
> >
> > s.
> >
> >
> > > On Jan 19, 2016, at 9:46 AM, [e-mail] wrote:
> > >
> > > Hi Les,
> > >
> > > IMO, “treat the sending node as NOT SR-MPLS capable for globally
> > > scoped
> > SIDs” may lead to confusion and let think that only Adj-SID can be used.
> > > “NOT SR-MPLS capable” is really strong, and may prevent the PHP case
> > Bruno was describing.
> > > May be we can add a sentence to precise what the statement means like
> :
> > “This means that the sending node is not able to process MPLS labels
> > mapped to globally scope SIDs.”.
> > >
> > >
> > > Stephane
> > >
> > >
> > > From: spring [mailto:[e-mail]] On Behalf Of Les
> > > Ginsberg (ginsberg)
> > > Sent: Saturday, January 16, 2016 01:13
> > > To: Uma Chunduri; DECRAENE Bruno IMT/OLN
> > > Cc: [e-mail]; Henderickx, Wim (Wim)
> > > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > Uma –
> > >
> > > It is true that the neighbor of the dysfunctional node cannot
> > > install
> > outgoing labels for paths via the dysfunctional node. That is
> > precisely the meaning of “treat the sending node as NOT SR-MPLS
> > capable for globally scoped SIDs”.
> > >
> > > This does not mean that “global SID advertisements should be ignored”.
> > And I do not see that it could in any way be interpreted to imply that.
> > >
> > > Please hit the “reset button” and try looking at this with a fresh
> > > perspective. J
> > >
> > >    Les
> > >
> > >
> > > From: Uma Chunduri [mailto:[e-mail]]
> > > Sent: Friday, January 15, 2016 3:56 PM
> > > To: Les Ginsberg (ginsberg); [e-mail]
> > > Cc: [e-mail]; Henderickx, Wim (Wim)
> > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > Les,
> > >
> > > In-line [Uma]:
> > >
> > > --
> > > Uma C.
> > >
> > > From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
> > > Sent: Friday, January 15, 2016 12:22 PM
> > > To: Uma Chunduri; [e-mail]
> > > Cc: [e-mail]; Henderickx, Wim (Wim)
> > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > Uma –
> > >
> > > I have no idea how you translate:
> > >
> > > Receivers of an invalid SRGB MUST ignore the SRGB and treat the
> > > sending
> > node as NOT SR-MPLS capable for globally scoped SIDs.
> > >
> > > into
> > >
> > > Should not consider any global SIDs, because the advertised global
> > > SIDs are not trustworthy any more
> > >
> > > SRGB defines the node-local label space which has been reserved for
> > > use
> > by SR on that node.
> > > [Uma]:  …and also the upstream neighboring node to compute and
> > > install
> > the outgoing label J.
> > >
> > > Global SIDs define the index which is to be used into the node
> > > specific
> > SRGBs to map the index into the correct node-specific label.
> > > [Uma]: ..of both advertising node’s own SRGB locally and the SRGB of
> > computed shortest path neighbor.
> > >
> > > While I will do my best to make the language in the draft clear and
> > > unambiguous,
> > >
> > > [Uma]: thx!
> > >
> > > I am frankly at a loss to understand how you concluded that the SRGB
> > related statement says anything whatsoever about SID advertisements.
> > > [Uma]: because of this
> > > “sending node as NOT SR-MPLS capable for globally scoped SIDs”
> > > hence the conclusion of not using the global SIDs!!
> > >
> > >
> > >    Les
> > >
> > >
> > > From: Uma Chunduri [mailto:[e-mail]]
> > > Sent: Friday, January 15, 2016 10:13 AM
> > > To: Les Ginsberg (ginsberg); [e-mail]
> > > Cc: [e-mail]; Henderickx, Wim (Wim)
> > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > Les,
> > >
> > > Thanks. My quick response below [Uma2]:
> > >
> > > --
> > > Uma C.
> > >
> > > From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
> > > Sent: Thursday, January 14, 2016 5:28 PM
> > > To: Uma Chunduri; [e-mail]
> > > Cc: [e-mail]; Henderickx, Wim (Wim)
> > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > Uma –
> > >
> > > Thanx for the response.
> > > Inline.
> > >
> > > From: Uma Chunduri [mailto:[e-mail]]
> > > Sent: Thursday, January 14, 2016 3:34 PM
> > > To: Les Ginsberg (ginsberg); [e-mail]
> > > Cc: [e-mail]; Henderickx, Wim (Wim)
> > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > Dear Les, Bruno,
> > >
> > > Thanks for a great discussion on this sticky issue.
> > >
> > > Couple of things:
> > >
> > > 1.       Les, I support advertising explicit SR capability of the node; meaning
> > this doesn’t have  to be tied to one or more SRGB range advertisements.
> > > Though for example, OSPF draft doesn’t say anything about ‘no srgb
> > ranges’ in SID/Label Range TLV, my vote is to be explicit about it.
> > > I also agree to change IS-IS document to change and to align to the rest.
> > >
> > > [Les:] IN the case of OSPFv2 there is a separate TLV for advertising
> > algorithm support. This can be used to infer SR-MPLS support for local
> > labels for IPv4. There is no language in the OSPFv2 draft which
> > requires SRGB to be sent.
> > > In the case of OSPFv3, SR Forwarding Capabilities are advertised in
> > > the
> > OSPF Router Informational Capabilities TLV. Again there is no
> > requirement to advertise SRGB – so the forwarding capabilities info
> > can be used to infer support for SR-MPLS local SID support.
> > >
> > > If you think the OSPF draft language is not explicit enough I
> > > suggest you
> > make comments to the OSPF-WG list.
> > >
> > > 2.       Revised proposal below is good and I agree on -  there is no
> > dependency of SRGB for locally scoped ADJ side it should not be
> > effected because of incorrect SRGB.
> > > -          I would say making this change to remove support for local ADJ sids
> > because of incorrect received SRGB for anode is a bigger change for us
> > (E///) at least.
> > >
> > > >2)Receivers of an invalid SRGB MUST ignore the SRGB and treat the
> > sending node as NOT SR-MPLS capable for globally scoped SIDs.
> > >
> > > A-----B----C-----D
> > >
> > > Consider the above network – if you are node A and you are dealing
> > > with a
> > “conflicting range from node D” but valid ranges from node B – you are
> > saying drop  all prefixes with global SIDs.
> > >
> > > [Les:] No – no such statement is made. The statement is “treat the
> > > sending
> > node as NOT SR-MPLS capable for globally scoped SIDs.”. The sending
> > node in your example is “D”. No changes are made as regards SR-MPLS
> > support for A, B, C. This in fact is not much different than what you
> > MUST do today even with a valid SRGB – because you have to check
> > whether the given SID is within the (set of) SRGB range(s) advertised
> > by your nexthop. If your nexthop is D then in this example no global
> > SID will map to a valid label in D’s forwarding plane – so C MUST NOT
> > install an outgoing label when forwarding traffic via D.
> > >
> > > [Uma2]: Precisely and I initially expected only node C, which
> > > eventually
> > uses   node D’s SRGB recognizes the conflicts in SRGB and consider D is
> ”NOT
> > SR-MPLS” capable. But the above statement doesn’t reflect this:
> > > “Receivers of an invalid SRGB MUST ignore the SRGB” è here D’s SRGB
> > > is
> > received by all nodes and for this example at node A; per this
> > statement it would ignore these SRGB’s during decision process and
> > w.r.t “sending node as NOT SR-MPLS capable for globally scoped SIDs.”
> > Should not consider any global SIDs, because the advertised global
> > SIDs are not trustworthy any more based on the earlier discussions on this
> thread.
> > > Perhaps as per your response above, you might want to say the
> > “neighboring upstream receivers should not use these invalid SRGB
> > ranges MUST ignore the…”.
> > >
> > > Evidently, the difference here is to abandon the node which is
> > > sending
> > “corrupted SRGBs” (as now its mandatory to have sending side checks)
> > as an SR-MPLS node for global SIDs by entire  network or only upstream
> > neighbors which could be installs the labels in the forwarding with
> > these “corrupted SRGBs”. I prefer modified language to reflect the intent
> correctly.
> > >
> > > Hope this helps.
> > >
> > >    Les
> > >
> > >
> > > But, I see you are asking this even though outgoing label is
> > > completely
> > governed by node B (which is advertising valid ranges) in this case.
> > Though this  is a bigger change  and ideally should be applicable to
> > only C , it  is  ok to me given the consensus on when senders MUST
> > advertise (non-conflicting
> > ranges) and  still conflicting range is seen.
> > >
> > > Most of the checks whatever possible for SRGBs, mapping server SID
> > > range
> > conflicts etc. must be prevented locally and this should be  mandated
> > (individual protocol/architecture/conflict document) somewhere.
> > However mapping server SID ranges is a completely different beast and
> > can be discussed some other day on how a receiver should handle the
> > conflicts there.
> > >
> > > --
> > > Uma C.
> > >
> > >
> > > From: spring [mailto:[e-mail]] On Behalf Of Les
> > > Ginsberg (ginsberg)
> > > Sent: Thursday, January 14, 2016 12:53 PM
> > > To: [e-mail]
> > > Cc: [e-mail]; Henderickx, Wim (Wim)
> > > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > Bruno (and everyone) –
> > >
> > > The remaining point to be discussed seems to be whether – when an
> > invalid SRGB is detected by receivers – the offending node should be
> > considered SR-MPLS incapable for both local and global SIDs or whether
> > we should only consider the node MPLS-SR incapable for Global SIDs.
> > The latter proposal has some merit because SRGB is only used in support of
> global SIDs.
> > However, in order to do this we must insure that all the protocol
> > drafts are consistent with this concept i.e. that SR-MPLS support has
> > two scopes and that the conditions necessary for supporting each of
> > the two scopes are not identical.
> > >
> > > For locally scoped SIDs it is sufficient that the node indicate that
> > > it supports
> > SR-MPLS for specific address families.
> > > For Globally scoped SIDs the node also has to provide a valid SRGB.
> > >
> > > My reading of the existing protocol drafts in this regard is as follows:
> > >
> > > https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-segment-rout
> > > in
> > > g-extensions/
> > > https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-ext
> > > en
> > > sions/
> > >
> > > OSPF drafts are consistent with the above.
> > >
> > > https://www.ietf.org/id/draft-ietf-idr-bgp-prefix-sid-02.txt
> > >
> > > BGP only has defined support for globally scoped SIDs – so no issue
> > > here
> > either.
> > >
> > > https://www.ietf.org/id/draft-ietf-isis-segment-routing-extensions-06.
> > > txt
> > >
> > > Here there is an issue. Section 3.1 specifies the contents of the
> > > SR-
> > Capabilities Sub-TLV which includes advertisement of both the SR-MPLS
> > support per address-family AND the SRGB. The text states:
> > >
> > > “One or more SRGB Descriptor entries…”
> > >
> > > So currently it is not valid to send the sub-TLV with no SRGB Descriptors.
> > This text would have to be altered to indicate that the SRGB
> > Descriptors MAY be omitted. This could cause backwards compatibility
> > issues with early deployments as a strict interpretation of the draft
> > would cause such a sub- TLV to be rejected. However, given that local
> > SR-MPLS support only is an unlikely case, I think such a change could
> > be acceptable as there should be sufficient time for all existing
> > implementations to be upgraded before such an exceptional case would
> > need to be deployed (if indeed that is ever required).
> > >
> > > Assuming that the IS-IS draft authors and the WG are willing to make
> > > the appropriate change in the IS-IS draft then I provide a revised
> > > definition of how to handle an invalid SRGB below. I ask all the
> > > folks who have already indicated their approval/disapproval of the
> > > previous proposal to review the revised proposal and indicate their
> > > opinion. Of course I also want to encourage folks who have not yet
> > > voiced their opinion to respond as well. J
> > >
> > > Thanx for all the good discussion – I think the proposal is better for it.
> > >
> > >    Les
> > >
> > > Revised Proposal:
> > > 1)SRGB configuration is a local matter. Conforming to the
> > > specification
> > requirement of NOT advertising overlapping SRGB ranges is totally
> > within the control of the local node. Misconfigurations can and MUST
> > be detected BEFORE they are advertised.
> > >
> > > 2)Receivers of an invalid SRGB MUST ignore the SRGB and treat the
> > > sending
> > node as NOT SR-MPLS capable for globally scoped SIDs.
> > >
> > > 3)Support for locally scoped SIDs is unaffected by the
> > presence/absence/validity of SRGB advertisements.
> > >
> > >
> > > From: [e-mail]
> > [mailto:[e-mail]]
> > > Sent: Thursday, January 14, 2016 12:30 AM
> > > To: Les Ginsberg (ginsberg)
> > > Cc: [e-mail]; Henderickx, Wim (Wim)
> > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > Les,
> > >
> > > Please see inline [Bruno2]
> > >
> > > From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
> > > Sent: Thursday, January 14, 2016 12:49 AM
> > > To: DECRAENE Bruno IMT/OLN
> > > Cc: [e-mail]; Henderickx, Wim (Wim)
> > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > Bruno -
> > >
> > > From: [e-mail]
> > [mailto:[e-mail]]
> > > Sent: Wednesday, January 13, 2016 1:13 AM
> > > To: Les Ginsberg (ginsberg)
> > > Cc: [e-mail]; Henderickx, Wim (Wim)
> > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > Les,
> > >
> > > Thanks for the summary of your position.
> > > Mine inlined [Bruno]
> > >
> > >
> > > From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
> > > Sent: Tuesday, January 12, 2016 10:06 PM
> > > To: DECRAENE Bruno IMT/OLN
> > > Cc: [e-mail]; Henderickx, Wim (Wim)
> > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > Bruno –
> > >
> > > Taking a step back – resummarizing my position:
> > >
> > > 1)SRGB configuration is a local matter. Conforming to the
> > > specification
> > requirement of NOT advertising overlapping SRGB ranges is totally
> > within the control of the local node. Misconfigurations can and MUST
> > be detected BEFORE they are advertised.
> > > [Bruno] Agreed.
> > >
> > > 2)Receivers of an invalid SRGB MUST ignore the SRGB and treat the
> > > sending
> > node as NOT SR-MPLS capable.
> > > [Bruno] “Drop all” (SRGB range) is equally safe. I don’t recall that
> > > you
> > provided any argument against it.
> > >
> > > [Les:] In an earlier reply to Stephane I stated:
> > >
> > > <snip>
> > > You are suggesting that a node which is not capable of supporting
> > > SR-MPLS
> > dataplane for prefix-SIDs should still be allowed to support ADJ-SIDs
> > – although it would have to be restricted to local SIDs  (ADJ-SIDs can
> > be assigned from the global SID space - just not the most common
> > usage). While you may be right in that such a practice is not
> > explicitly forbidden by any of the specifications, I am struggling to find a real
> world use case.
> > >
> > > Doing so certainly complicates implementations. Implementations
> > > today
> > verify whether a node supports SR-MPLS before using SR-MPLS
> > advertisements (prefix-SIDs, ADJ-SIDs). You are proposing that this
> > logic be enhanced to treat the case where the node has sent an invalid
> > SRGB as if the node is still SR-MPLS capable but for local SIDs only.
> > I don’t deny this could be done – I just don’t understand why.
> > >
> > > <end snip>
> > > [Bruno2] 3 points :
> > > a) Safety/validity: I’m still reading no argument saying that « Drop
> > > All” is less
> > safe than “SR Incapable”. Can we agree on this?
> > > b) Use cases: Local Segments and in particular Adjacency Segments
> > certainly have use cases. Are you arguing this? If not, “Drop All” has
> > the benefit of not dropping the traffic crossing that node using
> > Local/Adjacency segments.  More on this next few lines.
> > > c) Implementation complexity: 1) this is difficult to measure hence
> > > agree
> > on. If your implementation were open source, we could probably discuss
> > it more easily. 2)This may be implementation specific. 3) We have
> > already discussed this
> >
> https://mailarchive.ietf.org/arch/msg/spring/nAoOL8tCF4qXHYK7c2dIu3Xd4
> > 7 A  In short, before using a global SID, existing implementations
> > must also check that this global SID falls within the SRGB. Hence
> > dropping all the SRGB ranges would already be identified by
> > implementation with no changes.
> > >
> > > In subsequent comments no one has indicated that there is such a use
> > case. In the interest of simplicity I am therefore in favor of the
> > “NOT SR-MPLS capable” approach.
> > > [Bruno2]
> > > - I did indicated use case in existing implementations:
> > >
> >
> https://mailarchive.ietf.org/arch/msg/spring/FuMaSOnwO3WvtmMWT9SzV
> > 8jbT
> > > pE
> > > - In the context of this discussion, one router
> > > implementation/controller
> > would still be able to cross/use the node advertising conflicting SRGB
> > ranges by using a local adjacency segment. You may not want to
> > implement this use case, but I don’t see a reason to forbid this.
> > > - And again, local/adjacency are already defined and implemented,
> > because there were use cases.
> > >
> > > 3)All proposals to use part of the invalid advertisement run the
> > > risk of
> > making the problem worse and are based upon assumptions which cannot
> > be verified.
> > > [Bruno] This part is about trade-off and opinions. I agree that the
> > consequences of misrouting are more adverse than the one of dropping
> > traffic. In theory, relative probability of occurrence would also need
> > to be taken into account.
> > > I had the impression that we could agree on Drop all, based on a
> > > shared
> > analysis.
> > >
> > > 4)AS there is no valid reason why a node should send an invalid
> > > range (see
> > #1 above) I have no interest in investing analysis time or
> > implementation and test time in “guess work”.
> > > [Bruno] We agree that there is no valid reason and that this is a
> > > case of
> > error.  But bug do happens. If we need a consistent behavior across
> > the network, we need to specify the reaction to errors. I personally
> > think that this choice would be better if based on a shared analysis.
> > It bothers me a bit that the editor of the candidate document has no
> > interest in investing analysis time.
> > >
> > > [Les:] I don’t know if I can make you feel more comfortable, but let
> > > me
> > reemphasize  why I do not see analysis in this case as worthwhile.
> > > All options which involve using a portion of the invalid
> > > advertisement
> > require us to make assumptions about what we think the node which
> > advertised the invalid range is actually doing when installing labels
> > in its forwarding plane. Nothing about the invalid advertisement can
> > be reliably used to know what the advertising node is doing – nor to
> > predict what behavior is more likely. It is therefore not possible to
> > do a tradeoff analysis which is other than pure guesswork. I don’t
> > actually need to do the analysis to know this.
> > >
> > >    Les
> > >
> > > When we start discussing the second topic (SID conflicts) we have a
> > qualitatively different context. There independent configurations are
> > in play – so a single node does not have full control, human error
> > plays a role, and it makes sense to analyze the best resolution strategy.
> > > But in the case of SRGB the local node has full control, human error
> > > can be
> > detected before it is advertised, and there simply is no justification
> > for trying to compensate for an implementation which has clearly shown
> > it is untrustworthy.
> > > [Bruno] “There is simply no justification” is an overstatement.
> > > Looking
> > outside of SR, discussion on error handling in BGP could be found in
> > draft- ietf-grow-ops-reqs-for-bgp-error-handling and RFC 7606.
> > > -- Bruno
> > >
> > >    Les
> > >
> > >
> > > From: [e-mail]
> > [mailto:[e-mail]]
> > > Sent: Tuesday, January 12, 2016 9:50 AM
> > > To: Les Ginsberg (ginsberg)
> > > Cc: [e-mail]; Henderickx, Wim (Wim)
> > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > Les,
> > >
> > > Please see inline [Bruno2]
> > >
> > > From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
> > > Sent: Tuesday, January 12, 2016 4:38 PM
> > > To: DECRAENE Bruno IMT/OLN
> > > Cc: [e-mail]; Henderickx, Wim (Wim)
> > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > Bruno -
> > >
> > > From: [e-mail]
> > [mailto:[e-mail]]
> > > Sent: Tuesday, January 12, 2016 3:51 AM
> > > To: Les Ginsberg (ginsberg)
> > > Cc: [e-mail]; Henderickx, Wim (Wim)
> > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > Les,
> > >
> > > Please see inline 1 point below [Bruno]
> > >
> > > From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
> > > Sent: Tuesday, January 12, 2016 12:41 AM
> > > To: Fedyk, Don; HENDERICKX, Wim (Wim); DECRAENE Bruno IMT/OLN
> > > Cc: LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; [e-mail]
> > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > Don -
> > >
> > > From: Fedyk, Don [mailto:[e-mail]]
> > > Sent: Monday, January 11, 2016 3:06 PM
> > > To: Les Ginsberg (ginsberg); HENDERICKX, Wim (Wim);
> > > [e-mail]
> > > Cc: LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; [e-mail]
> > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > Hi  Les
> > >
> > > So you are saying a node that generates inconsistent SRGB
> > > (overlapping
> > ranges) all by itself should be treated Segment routing incapable and
> > this should be easy to detect by any correctly performing neighbor?
> > > [Les:] Yes. Detection is easy – you simply check for overlapping
> > > ranges in
> > the advertisement from an individual node.
> > > What is generating all the discussion is whether we should treat
> > > that node
> > as SR-MPLS incapable (a couple of variants there) or try to massage
> > the received information into a partially usable form.
> > >
> > > This is probably as good a time as any for me to reply to the latter
> proposal.
> > >
> > > All of the “use some of the information” variants (detailed at
> > > length in
> > Bruno’s posts) depend upon the node which sent the inconsistent SRGB
> > information itself performing the same transformation as the receivers.
> > > [Bruno] This is a good technical point to identify. Thanks. I’ll add
> > > it in the
> > text. IINM, among the options being discussed:
> > > Drop all, Drop from conflict, SR incapable do _not_ require any
> > > action on
> > the advertising node. not to mention consistent action with all others
> nodes.
> > >
> > > [Les2:] Drop from conflict makes an assumption that the faulty node
> > > is
> > using the ranges in the order advertised and that the reason the
> > conflict exists is because the later ranges were configured
> > incorrectly. But we don’t know this for certain. For example – the intended
> set of ranges is:
> > >
> > > [1000, 1099]
> > > [2000, 2099]
> > >
> > > But something gets mangled when formatting the sub-TLV and what is
> > advertised turns out to be:
> > >
> > > [1000, 2099]
> > > [2000, 2099]
> > >
> > > Using drop from conflict assumes you can use SIDs 0 – 1099 safely,
> > > but in
> > fact SIDs greater than 99 will use a label that the faulty node (which
> > is using the first set of ranges above) is NOT using for SR.
> > >
> > > This looks less egregious than other options only because the
> > > assumption
> > that the first range which is advertised is correct seems “reasonable”
> > or “likely” – but in fact we don’t know that.
> > >
> > > [Bruno2] Yes, and I have updated the text in my document to include
> > > your
> > point.. But I don’t think it’s about « reasonable” or “likely”. In my
> > view, it’s about trusting (or not) a received data which is correct
> > from both a syntax and semantic perspective.
> > > We could define an option which would be dropping before the conflict.
> > Would that make a difference for you?
> > > Because, I can equally build an example where your proposition would
> > > be
> > erroneous. e.g.
> > > the intended set of ranges is:
> > > [1000, 1099]
> > > [2000, 2099]
> > >
> > > But something gets mangled when using formatting the sub-TLV and
> > > what
> > is advertised turns out to be:
> > > [1000, 1199]
> > >       [2000, 2099]
> > >
> > > You believe you can use SID 110 based on the assumption that the
> > > ranges
> > which are advertised are correct, but in fact you don’t know that.
> > >
> > > And if we don’t believe in data which looks like correct from both a
> > > syntax
> > and semantic perspective, we should stop using protocols.
> > >
> > > That being said, I think we now have identified the key point of the
> > > discussions. If so, now it would be about making a trade-off between
> > > Traffic dropping or mis-routing. (as personally I see
> > > “implementation complexity” being a significant point, compared
> > > these 2.)
> > >
> > > --
> > >
> > > Drop the conflicting one, Merge, Merge and re-order _do_ require a
> > > new
> > behavior on the advertising node, consistent with all others nodes.
> > >
> > > [Les:] Agreed.
> > >
> > > But there is a higher order issue here for me – which is that all
> > > options
> > other than “Drop all” variants have to make an assumption about the
> > faulty node behavior which cannot be verified – which means the
> > attempt to minimize the damage may actually do further harm. This is
> > not acceptable to me.
> > >
> > >    Les
> > >
> > > Please comment if you disagree.
> > > -- Bruno
> > >
> > > This to me is a non-starter. You have a node which has a bug in its
> > implementation. Trusting that the node will recognize  that it has
> > sent invalid info and needs to transform it when using it internally isn’t
> reasonable.
> > Whether the bug which caused invalid info to be sent also affects the
> > use of that information internally is something you simply have no way to
> know.
> > Basing the behavior of the rest of the network on that assumption
> > isn’t reasonable to me – attempts to determine which data
> > transformation might yield “better” results is pure guesswork since
> > you cannot rely on a buggy implementation behaving in a predictable way.
> > >
> > >    Les
> > >
> > >
> > > Don
> > >
> > > From: spring [mailto:[e-mail]] On Behalf Of Les
> > > Ginsberg (ginsberg)
> > > Sent: Monday, January 11, 2016 5:37 PM
> > > To: Fedyk, Don; HENDERICKX, Wim (Wim); [e-mail]
> > > Cc: LITKOWSKI Stephane SCE/OINIS; Martin Horneffer; [e-mail]
> > > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > Folks –
> > >
> > > This thread is about SRGB inconsistency. SRGB inconsistency is an
> > > INTRA-
> > node issue. There is no SRGB conflict issue between nodes.
> > >
> > > There will be a separate thread about SID conflict issues – where
> > > inter-
> > node conflicts certainly are possible – but that is NOT what we are
> > discussing in this thread.
> > >
> > > Perhaps some folks would like to revise their responses with this in mind?
> > >
> > >    Les
> > >
> > >
> > > From: Fedyk, Don [mailto:[e-mail]]
> > > Sent: Monday, January 11, 2016 1:41 PM
> > > To: HENDERICKX, Wim (Wim); [e-mail]
> > > Cc: Les Ginsberg (ginsberg); Martin Horneffer; [e-mail];
> > > LITKOWSKI Stephane SCE/OINIS
> > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > Hi Wim
> > >
> > > If I understand your Option 1) it can occur, for example, if two
> > > nodes that
> > have a conflicting SRGB but they are not directly connected and as
> > such there can be a race condition where they advertise SRGB conflict at
> roughly the
> > same time.  So nodes in the middle have to decide who wins.   (If that is the
> > case, that is the same issue we had in SPB for certain conflicts and
> > the solution was to use NodeID as a tie breaker to decide which node
> > wins.)  In the SRGB case the loosing Node would also receive the
> > winning nodes SRGB and would “know” there is a conflict and it lost.
> > It is true that the looser could have had the SRGB established for a
> > long time and suddenly become Segment Routing incapable because of a
> > higher priority node’s conflicting config.  However I think that is
> > the nature of this situation SRGB information it must be consistent.
> > The thing to make sure of is that any SRGB configuration can be
> > relatively easily migrated to a non-conflicting range and a
> > configuration model that does not make it easy to accidentally create SRGB
> conflicts into an existing network.
> > >
> > > Not sure I follow your option 2 but option 1 can be easy to
> > > determine
> > winners and losers (not right and wrong J ).
> > >
> > > Cheers,
> > > Don
> > >
> > > From: spring [mailto:[e-mail]] On Behalf Of
> > > HENDERICKX, Wim (Wim)
> > > Sent: Monday, January 11, 2016 3:07 PM
> > > To: [e-mail]
> > > Cc: Les Ginsberg (ginsberg); Martin Horneffer; [e-mail];
> > > LITKOWSKI Stephane SCE/OINIS
> > > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > I believe we agree to minimise the network impact when SRGB data is
> > inconsistent.
> > > Option 1 is we ignore a advertisements of some nodes. The main issue
> > > I
> > see with this is determining who is right/wrong. Implementation is
> > rather easy, but you will impact traffic from certain nodes in some
> > case as outlined below.
> > > Option 2 is you try to disseminate something out of the information
> > > and try
> > to determine a consistent behaviour across all node. Implementation is
> > more difficult, but I believe there is more coverage/chances to meet
> > the overall objective.
> > >
> > > My 2 cents.
> > >
> > > From: Bruno Decraene <[e-mail]>
> > > Date: Monday 11 January 2016 at 17:53
> > > To: Wim Henderickx <[e-mail]>
> > > Cc: Martin Horneffer <[e-mail]>, "Les Ginsberg (ginsberg)"
> > > <[e-mail]>, "[e-mail]" <[e-mail]>, Stephane
> > > Litkowski <[e-mail]>
> > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > Hi Wim,
> > >
> > > I read that you are pointing out the difficulty to identify the inconsistency.
> > > If so, this point is common to all options being discussed.
> > >
> > > I may be missing some of your points. This thread is about
> > > inconsistency in
> > the SRGB ranges advertised by _one_ node. I’m not sure to see your
> > “startup scenario” nor the “merge network scenario”. Could you please
> > elaborate?
> > >
> > > Thanks,
> > > Bruno
> > >
> > > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-
> > lucent.com]
> > > Sent: Wednesday, January 06, 2016 8:19 PM
> > > To: DECRAENE Bruno IMT/OLN
> > > Cc: Martin Horneffer; Les Ginsberg (ginsberg); [e-mail];
> > > LITKOWSKI Stephane SCE/OINIS
> > > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > If you avoid an inconsistency in an SRGB announcement there is
> > > multiple
> > scenario’s in which you determine who is right/wrong:
> > > 	• Assume you are in a startup scenario, it is very hard to
> > > determine
> > who is consistent and who is not
> > > 	• If you are in a running network and you add a new node or have a
> > different config on 1 node, you can determine it
> > > 	• If you merge a network and the config is wrong in one part but
> > > not
> > in the other part of the network.
> > >
> > > I see this strategy work in some case but in others I see challenges
> > > to determine what is right and what is wrong, hence my question
> > >
> > > From: Bruno Decraene <[e-mail]>
> > > Date: Wednesday 6 January 2016 at 19:03
> > > To: Wim Henderickx <[e-mail]>
> > > Cc: Martin Horneffer <[e-mail]>, "Les Ginsberg (ginsberg)"
> > > <[e-mail]>, "[e-mail]" <[e-mail]>, Stephane
> > > Litkowski <[e-mail]>
> > > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > Hi Wim,
> > >
> > > Many thanks for taking part in the discussion.
> > > Could you please elaborate? e.g. what do you mean by ”who” and
> “wrong”
> > on what?
> > > I could see multiple interpretations, but it would probably be
> > > faster if you
> > elaborate by yourself.
> > >
> > > Thanks
> > > -- Bruno
> > >
> > > From:spring [mailto:[e-mail]] On Behalf Of
> > > Henderickx, Wim (Wim)
> > > Sent: Tuesday, January 05, 2016 7:41 PM
> > > To: Martin Horneffer; Les Ginsberg (ginsberg); [e-mail];
> > > LITKOWSKI Stephane SCE/OINIS
> > > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > My main question on the proposal is how do we tell who is right and
> > > who is
> > wrong?
> > >
> > > From: spring <[e-mail]> on behalf of Martin Horneffer
> > > <[e-mail]>
> > > Date: Tuesday 5 January 2016 at 13:05
> > > To: "Les Ginsberg (ginsberg)" <[e-mail]>, "[e-mail]"
> > > <[e-mail]>, Stephane Litkowski
> > > <[e-mail]>
> > > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution:
> > > SRGB INCONSISTENCY
> > >
> > > Hello Les, Acee, Stephane, everyone,
> > >
> > > happy new year!
> > >
> > > From an operator's (carrier's) point of view I clearly and strongly
> > > support
> > this alternative solution: Treat an inconsistent set of SRGB
> > announcements as broken and ignore it.
> > >
> > >  - It is the simplest solution.
> > >  - It only affects traffic of the badly configured and implemented router.
> > >  - It gives a clear indication to the operator where they have to
> > > repair
> > something.
> > >
> > > With respect to Stephane's comments:
> > >  - I would also support a repetition or clarification that an
> > > inconsistent set of
> > SRGB annoucements is broken.
> > >  - No strong opinion from my side as how to define the offending
> > > node as
> > non-SR-capable as I don't see any use case for nodes with only
> > adjacency SIDs.
> > >
> > > Best regards,
> > > Martin
> > >
> > >
> > > Am 04.01.16 um 06:55 schrieb Les Ginsberg (ginsberg):
> > > One of the topics discussed in
> > > https://datatracker.ietf.org/doc/draft-
> > ginsberg-spring-conflict-resolution/ is how to handle inconsistent
> > SRGB advertisements from a given node.
> > >
> > > The draft defines one possible solution -from Section 2:
> > >
> > > " Each range is examined in the order it was advertised.  If it does
> > >    not overlap with any advertised range which preceded it the
> > >    advertised range is used.  If the range overlaps with any preceding
> > >    range it MUST NOT be used and all ranges advertised after the first
> > >    encountered overlapping range also MUST NOT be used."
> > >
> > > This is one instance of a class of solutions which attempt to make
> > > use of
> > part of the advertisements even when there is some inconsistency
> > (overlap) in the set of SRGB ranges received. A more complete
> > discussion of this class of solutions can be seen in
> > https://mailarchive.ietf.org/arch/attach/spring/txtk0n56G.txt - many
> > thanx to Bruno for writing this.
> > >
> > > However, there is an alternative solution which was suggested
> > > (notably by
> > Acee Lindem) after the draft was written. This alternative is to
> > ignore the entire set of SRGB advertisements and treat the problematic
> > router as if it were not SR MPLS capable. This alternative was
> > discussed during the presentation in SPRING WG at IETF94 (see
> > https://www.ietf.org/proceedings/94/slides/slides-94-spring-2.pdf slide
> #3).
> > It is also discussed in Bruno's post
> > (https://mailarchive.ietf.org/arch/attach/spring/txtk0n56G.txt - see
> > Section 2.2).
> > >
> > > The basis of the alternative solution is that a correct
> > > implementation should
> > never allow inconsistent SRGB ranges to be successfully configured
> > (let alone advertised). So this is not a case of a misconfiguration –
> > it is a case of a defective implementation. It  then seems appropriate
> > to put the onus on the originating router to only send valid SRGB
> > advertisements rather than forcing all the receivers to try to
> > "correct" the invalid information in some consistent way. This has a number
> of advantages:
> > >
> > > 1.       It is by far the simplest to implement
> > > 2.       It isolates the router which is untrustworthy
> > > 3.       As the problem can only occur as a result of a defective
> > implementation the behavior of the originating router is unpredictable
> > – it is therefore safer not to use the information
> > >
> > > It is worth noting that since the invalid advertisement is the
> > > result of some
> > sort of defect in the originating router’s implementation, it is not
> > safe to assume that the source will actually be using the advertised
> > SRGB in a manner consistent with the selective choice made by the
> receiving routers.
> > >
> > > I therefore propose that the above quoted text from
> > https://datatracker.ietf.org/doc/draft-ginsberg-spring-conflict-resolu
> > tion/
> > be replaced with the following:
> > >
> > > “The set of received ranges is examined . If there is overlap
> > > between any
> > two of the advertised ranges the entire SRGB set is considered invalid
> > and is ignored.
> > > The originating router is considered to be incapable of supporting
> > > the SR-
> > MPLS forwarding plane. Routers which receive an SRGB advertisement
> > with overlapping ranges SHOULD report the occurrence.”
> > >
> > > Comments?
> > >
> > >    Les
> > >
> > >
> > >
> > > _______________________________________________
> > > spring mailing list
> > > [e-mail]://www.ietf.org/mailman/listinfo/spring
> > >
> > >
> >
> __________________________________________________________
> > ____________
> > > ___________________________________________________
> > >
> > > 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.
> > >
> >
> __________________________________________________________
> > ____________
> > > ___________________________________________________
> > >
> > > 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.
> > >
> >
> __________________________________________________________
> > ____________
> > > ___________________________________________________
> > >
> > > 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.
> > >
> >
> __________________________________________________________
> > ____________
> > > ___________________________________________________
> > >
> > > 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.
> > >
> >
> __________________________________________________________
> > ____________
> > > ___________________________________________________
> > >
> > > 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.
> > >
> >
> __________________________________________________________
> > ____________
> > > ___________________________________________________
> > >
> > > 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.
> > >
> >
> __________________________________________________________
> > ____________
> > > ___________________________________________________
> > >
> > > 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.
> > >
> > > _______________________________________________
> > > spring mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/spring
> 
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring

_________________________________________________________________________________________________________________________

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.