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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Bruno -

Thanx for the quick review.
Please see my response to Stephane.
More inline.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, February 02, 2016 1:18 AM
> To: Les Ginsberg (ginsberg)
> Cc: [e-mail]; Uma Chunduri; Henderickx, Wim (Wim); Stefano Previdi
> (sprevidi); LITKOWSKI Stephane SCE/OINIS
> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
> INCONSISTENCY
> 
> Hi Les,
> 
> Thanks for the text. Looks good 2 me.
> 
> 2 comments:
> -  "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." does not fit well with the specific case
> where the node is the egress and PHP or explicit null is advertised. In this
> case the SRGB is not used for that global SID. One proposition  would be to
> remove that sentence, or :s/supporting/transiting    (but that would be
> adding a new specific case, where nothing is really required), or expliciting
> the specific case.
> 
> - Eventually, the text may also specify that the range MUST exclude the 0-15
> values. The whole SRGB should also probably be considered invalid in this
> case.
[Les:] [SR-MPLS] states:

" The Segment Routing Global Block (SRGB) values MUST be greater
      than 15 in order to preserve values 0-15 as defined in [RFC3032]."

   Les

> 
> Thanks,
> -- Bruno
> 
> > -----Original Message-----
> > From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
> > Sent: Tuesday, February 02, 2016 1:22 AM
> > 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/FuMaSOnwO3WvtmMWT9Sz
> > V
> > > > 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.