Re: [Isis-wg] draft-ginsberg-isis-l2bundles

["Ahmed Bashandy (bashandy)" <[e-mail]>]

Hi Hannes

Let me respond inline

Ahmed

On 8/21/2015 1:29 AM, Hannes Gredler wrote:
> hi ahmed,
>
> did some checking of "LAG-child LSPs" asks among my SP customers
> and what is not clear to me is:
>
> "why do we need IS-IS extensions for this ?"
>
> couple of observations:
>
> - your proposal of exposing sub-LAG LSPs is valid and there is
>    interest to run OAM traffic on LAG-child links
AB> Agreed, but keep in mind that OAM is NOT the only use case 
applicable by this draft
> - there is no receive side component in your draft -
>    i.e. IS-IS is used only as a northbound protocol
AB> TE RFCs, such as rfc 5305, 5307, 6119,.., did not specify a receive 
side component.
If they did and I missed them, then the receive side components in the 
TE rfcs are the same for draft-ginsberg-isis-l2bundles:)
> - there is general desire for label-predictability - so most SPs were
>    happy to *statically* allocate a label per LAG child link, such
>    that even no transmit side support is needed.
AB> I disagree with you regarding the existence of a general desire not 
to advertise static information. If that is the case, then we might as 
well not advertise anything static at all, such as static routes or 
static TE metric such as max BW
Besides label predictabiliy is an internal implementation and the 
existence of such predictability does not mean that the labels should 
not be advertised. Otherwise, we might as well not advertise any label 
at all in any protocol (e.g. LDP, RSVP, BGP) unless the label value is 
completely random.
> - there are some concerns to bloat the IGP (which does topology
>    discovery) with non routing related functions.
AB> The draft is proposing TE-related extensions just like other TE 
RFCs. Why did TE metrics become a bloat for this draft? Besides a good 
implementation is expected to only advertise these additional TE 
attributes via explicit configuration. So it would not be a bloat for a 
user who wants them.
> so coming back to stephane's argument about "BGP-LS" it seems that
> this is only relevant to operators which do not want to deploy
> BGP-LS on routers running LAGs.
AB> As Ebben mentioned (as well as myself in the email below), BGP-LS is 
a complementary not an alternative solution. Besides, I am not sure how 
to practically (or even possibly) use  BGP-LS on its own to advertise 
link-state information without IGPs (I did not want to argue about that 
in that thread because it is a different topic all together). If it is 
possible, then an operator that accepts running BGP-LS should completely 
refrain from advertising any TE attributes in IGPs.
>
> is that a fair summary ?
>
> /hannes
>
> On Mon, Aug 10, 2015 at 05:05:27PM -0700, Ahmed Bashandy (bashandy) wrote:
> |    Folks
> |
> |    In attempt to provide a relatively quantitative measurement of the
> |    proposed solutions to the problem at hand, I thought I would prepared a
> |    small comparison table between ISIS for L2 bundles, BGP-LS for L2 bundles,
> |    and changing all L2 bundles members to L3 links as unnumbered interfaces.
> |    I put +1 for (IMHO) what looks like an advantage, -1 for (IMHO) what looks
> |    like a disdavantage, and (0) what looks like a minor disadvantage or
> |    advantage
> |
> |    +------------------------------------------------------------------------+
> |    |                   |ISIS to advertise |BGP-LS to    |L2 bundles as      |
> |    |                   |L2 bundles        |advertise L2 |unnumbered         |
> |    |                   |                  |bundle       |interfaces in ISIS |
> |    |-------------------+------------------+-------------+-------------------|
> |    |Scalability        |Minimal scale     |Minimal scale|Significant scale  |
> |    |                   |overheard (+1)    |overhead (+1)|overhead (-1)      |
> |    |-------------------+------------------+-------------+-------------------|
> |    |Mandate the        |No (+1)           |Yes (-1)     |No (+1)            |
> |    |deployment of a    |                  |             |                   |
> |    |protocol that was  |                  |             |                   |
> |    |not deployed before|                  |             |                   |
> |    |-------------------+------------------+-------------+-------------------|
> |    |Impact on basic    |Minimal (+1)      |Minimal (+1) |Significant (-1)   |
> |    |routing            |                  |             |                   |
> |    |functionality      |                  |             |                   |
> |    |-------------------+------------------+-------------+-------------------|
> |    |Works for both P2P |Simple (+1)       |Simple (+1)  |Difficult          |
> |    |and LAN            |                  |             |(unnumbered not    |
> |    |                   |                  |             |easy with LANs)    |
> |    |                   |                  |             |(-1)               |
> |    |-------------------+------------------+-------------+-------------------|
> |    |Using 1 protocol   |Yes (+1)          |No (-1)      |Yes (+1)           |
> |    |for diverse        |                  |             |                   |
> |    |functionilities    |                  |             |                   |
> |    |-------------------+------------------+-------------+-------------------|
> |    |Exposing L2 info in|Yes (-1)          |Yes (-1)     |No (+1)            |
> |    |L3 protocol        |                  |             |                   |
> |    |-------------------+------------------+-------------+-------------------|
> |    |Protocol change    |Yes (-1)          |Yes (-1)     |No (+1)            |
> |    |-------------------+------------------+-------------+-------------------|
> |    |Risk               |Small (Minimal    |Medium (Have |Significant (Have  |
> |    |                   |impact on baseline|to deploy    |to make sure that  |
> |    |                   |functionality and |BGP-LS       |baseline           |
> |    |                   |managements tools |everywhere)  |functionality on   |
> |    |                   |while not         |(0)          |all routers as well|
> |    |                   |deploying any new |             |as management and  |
> |    |                   |protocol) (+1)    |             |monitoring tools   |
> |    |                   |                  |             |are not impacted by|
> |    |                   |                  |             |the sharp scale    |
> |    |                   |                  |             |increase) (-1)     |
> |    |-------------------+------------------+-------------+-------------------|
> |    |Sum                |5                 |-1           |-2                 |
> |    +------------------------------------------------------------------------+
> |
> |    One Important point, I agree with Ebben that BGP-LS is not an alternative
> |    to using ISIS but rather a complementary solution to be used by networks
> |    that do not use ISIS and OSPF. If we assume that BGP-LS will be used by
> |    networks that already employ BGP, then using ISIS and BGP-LS will have
> |    almost the same score
> |
> |    Thanks
> |
> |    Ahmed
> |
> |    On 8/7/2015 12:28 AM, [1][e-mail] wrote:
> |
> |  The gain is that there is no need for a new ISIS extension, you can use TLV22 as usual.
> |  IMO, maintaining a real adjacency is not a big deal moreover it allow for detection of MTU mismatch ...
> |  And as the interface is an IP interface, there is no more "layer breakage".
> |
> |  So to do this, no need of IETF standardization, just local behavior on the node.
> |
> |
> |  -----Original Message-----
> |  From: Acee Lindem (acee) [[2]mailto:[e-mail]]
> |  Sent: Friday, August 07, 2015 02:08
> |  To: LITKOWSKI Stephane SCE/IBNF; Ebben Aries; [3][e-mail] list ([4][e-mail])
> |  Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles
> |
> |  Hi Stephane,
> |
> |  On 8/6/15, 10:31 AM, [5]"[e-mail]"
> |  <[e-mail]> wrote:
> |
> |
> |  Acee,
> |
> |  Another possibility to address the requirement of TE per link within a
> |  LAG bundle may be to create L3 adjacencies on each link in addition to
> |  an adjacency for the bundle. This does not work today but ...
> |  This would be a new way to manage LAGs, IMHO (as I'm not an
> |  implementor), I don't see a reason for this to not work theorically.
> |  Then each L3 protocol has the choice to use a bundle-view or a per-link
> |  view. You will create more IGP adjacencies but that's not a big deal
> |  (CPU are quite big now :) ).
> |  This behavior is more clear than the one proposed in the draft, as the
> |  target is to provide a kind of layer 3 forwarding on layer 2 links ...
> |  here this would be a true layer 3 forwarding on layer 3 links.
> |
> |  Example :
> |
> |  Interface Port-Channel1
> |  Ip address 1.1.1.1/30
> |  Ip router isis
> |  Isis metric 100
> |  !
> |  Interface Te10
> |  Ip address 2.0.0.1/30
> |  Channel-group 1
> |  Ip router isis
> |  Isis metric max-metric
> |  !
> |  Interface Te20
> |  Ip address 3.0.0.1/30
> |  Channel-group 1
> |  Ip router isis
> |  Isis metric max-metric
> |  !
> |
> |  Thoughts ?
> |
> |  I don’t think you’d want to establish a separate adjacency over each of the LAG constituent links. I guess you may be inventing a lower overhead adjacency similar to a TE forwarding adjacency (RFC 4206) to represent the constituents. This would also work but I don’t see that much difference from the existing proposal other than the abstraction and that you have an anchor point for TE attributes (which could be a good thing if these proliferate).
> |
> |  Thanks,
> |  Acee
> |
> |
> |
> |
> |
> |
> |  -----Original Message-----
> |  From: Acee Lindem (acee) [[6]mailto:[e-mail]]
> |  Sent: Thursday, August 06, 2015 15:34
> |  To: LITKOWSKI Stephane SCE/IBNF; Ebben Aries; [7][e-mail] list
> |  ([8][e-mail])
> |  Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles
> |
> |
> |
> |  On 8/6/15, 9:19 AM, [9]"[e-mail]"
> |  <[e-mail]> wrote:
> |
> |
> |  I think this may have implications beyond SR but it seems there are
> |  other areas where LAGs (aka, link-bundles) have permeated into L3
> |  (e.g., BFD - RFC 7130).
> |
> |  [SLI] Fully agree, IMO, we must not let the doors wide open to this
> |  kind of permeation.
> |
> |  LAGs are ubiquitous and I think we are going to have to accommodate
> |  them in L3 protocols even if it is a layer violation. But this is just
> |  my opinion.
> |
> |  Thanks,
> |  Acee
> |
> |
> |
> |
> |
> |
> |  -----Original Message-----
> |  From: Acee Lindem (acee) [[10]mailto:[e-mail]]
> |  Sent: Thursday, August 06, 2015 14:53
> |  To: LITKOWSKI Stephane SCE/IBNF; Ebben Aries; [11][e-mail] list
> |  ([12][e-mail])
> |  Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles
> |
> |  Hi Stephane,
> |
> |
> |  On 8/6/15, 4:01 AM, [13]"[e-mail]"
> |  <[e-mail]> wrote:
> |
> |
> |  Hi Acee,
> |
> |  Some comments inline
> |
> |  -----Original Message-----
> |  From: Acee Lindem (acee) [[14]mailto:[e-mail]]
> |  Sent: Wednesday, August 05, 2015 19:24
> |  To: LITKOWSKI Stephane SCE/IBNF; Ebben Aries; [15][e-mail] list
> |  ([16][e-mail])
> |  Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles
> |
> |  Hi Stephane,
> |  I think the IS-IS advertisement is merely a consequence of the fact
> |  that we are satisfying the requirement of incorporating these L2
> |  links in the segment routing path.
> |  [SLI] Yes, and IMO, that's bad.
> |
> |
> |
> |
> |  - I still have some doubt on the reason to split LAGs for TE and
> |  keeping bundles for other protocols.
> |  - Regarding TE, I don't really see how BW use cases can work with
> |  this, as there may be some TE tunnels using the bundle and some using
> |  specific link, so evaluating the remaining BW per link and for the
> |  bundle is hard.
> |  - This "breaks" layers, IGP exposes Layer 3 topology by design, not
> |  layer
> |  2 ... if we want to expose layer 2, that's not an issue, it's a kind
> |  of multilayer TE approach and BGP-LS may so come in the picture and
> |  is a good candidate to retrieve topological information. I do not
> |  want to see IS-IS or OSPF becoming a topology discovery protocol for
> |  everything
> |  :
> |  while it's related to the Layer 3 topology it's fine to me to keep it
> |  in the IGP for other informations, may be we need to find another way.
> |
> |
> |  If we limit advertisement to BGP-LS, it will have the following impact:
> |
> |      1. All routers in the IS-IS domain that use link-bundles will
> |  need some form of BGP LS peering, either to the controller directly
> |  or through some intermediary.
> |  [SLI] Agree but I don't see this as a negative point, as I think most
> |  networks running TE, already have a BGP controlplane that can be reused.
> |
> |  If there is BGP-LS peering on all the routers, then I agree that this
> |  would work given the right local policy to specify what BGP-LS
> |  information each router advertises.
> |
> |  Thanks,
> |  Acee
> |
> |
> |
> |
> |
> |      2. Since the link-bundle itself is an IS-IS L3 link, one would
> |  need to correlate the information with the corresponding IS-IS link
> |  state information (assuming not every IS-IS router advertises the
> |  entire LSDB).
> |  [SLI] Agree there is a need of correlation, but correlation is
> |  required in all cases (in the current proposal, we advertise some
> |  parent link information).
> |
> |  Additionally, any time the information is coming from multiple
> |  sources, you are likely to trigger path computation more frequently.
> |  [SLI] I would say that's implementation dependent.
> |
> |
> |  I don’t think this added complexity warrants omitting them from the
> |  IGPs if we do, in fact, accept link bundle adjacency steering as a
> |  requirement.
> |
> |  Thanks,
> |  Acee
> |
> |
> |  On 8/5/15, 4:12 AM, "Isis-wg on behalf of [17][e-mail]"
> |  [18]<[e-mail] on behalf of [e-mail]>
> |  wrote:
> |
> |
> |  Hi,
> |
> |  Pls find some inline comments.
> |
> |  -----Original Message-----
> |  From: Ebben Aries [[19]mailto:[e-mail]]
> |  Sent: Wednesday, August 05, 2015 01:39
> |  To: LITKOWSKI Stephane SCE/IBNF; [20][e-mail] list
> |  ([21][e-mail])
> |  Subject: Re: [Isis-wg] draft-ginsberg-isis-l2bundles
> |
> |  I see BGP-LS extensions complementing this, not necessarily as a
> |  replacement.
> |  [SLI] It's for sure an option, but my point is do we need to
> |  continue to add extensions to both IGP and BGP LS ?
> |  Moreover I still have an issue with propagating L2 informations into
> |  layer 3 routing protocol  (not technically ... more from a design
> |  perspective).
> |  Let's say that tomorrow, you would like to advertise some L1
> |  information under your layer 2 information ... ?? As we are breaking
> |  layers, if you want to advertise some underlay topology, I would be
> |  in favor to not doing it in IGP.
> |
> |  For a use-case of a central entity learning these underlying l2
> |  attributes to then do whatever you wish (impose label stacks, etc..)
> |  - BGP-LS is a natural fit.
> |  [SLI] Nothing prevents to use BGP-LS in a distributed computation
> |  model.
> |
> |  For this to remain in the IGP, a consideration could be the
> |  propagation of these L2 attributes to then be included in TEDs for
> |  additional logic from headend nodes (network elements within the IGP
> |  domain) - e.g.
> |  control packet per member from a remote endpoint overriding remote
> |  hashing either by some policy/SLA or dynamic based off of per member
> |  utilization, etc..
> |
> |  [SLI] Even if TED was previously populated only by IGP (because
> |  there was nothing else), this is not the case anymore. TED is also
> |  populated by BGP-LS and we may be able to create also new processes
> |  to populate the TED. So you can imagine having your process managing
> |  LAGs to add those L2 TE information into the TED and then being able
> |  to export it through BGP-LS to other nodes through the BGP
> |  controlplane, so every one will have the same content in the TED.
> |
> |
> |  On 08/03/2015 07:02 AM, [22][e-mail] wrote:
> |
> |  Hi,
> |
> |
> |
> |  Thinking again about this draft, I wondering why not using BGP-LS
> |  for that purpose ?
> |
> |  I mean, the goal here is just to provide some topological
> |  information that are not related to IGP, as you want to keep L2
> |  bundles and so a single IP link. If you want to expose the
> |  underlaying topology, you may be able to do it in BGP-LS rather
> |  than adding this in the IGP as the information you want to expose
> |  is not necessary for the IGP to run.
> |
> |
> |
> |  Thx
> |
> |
> |
> |  Orange logo
> |  [23]<https://urldefense.proofpoint.com/v1/url?u=http://www.orange.com/
> |  &
> |  k
> |  =
> |  Z
> |  VNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywaGV%2FvoQ%3D%3D%0A
> |  &
> |  m
> |  =
> |  x
> |  DbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0A&s=75085ca9001f9
> |  c
> |  7
> |  a
> |  2
> |  4e6f23efb57f50f5d79a97cbadcbfe1ce65082d335dba35>
> |
> |
> |
> |  *Stephane Litkowski *
> |  Network Architect
> |  Orange/SCE/EQUANT/IBNF/ENDD/NDE
> |
> |  Orange Expert Future Networks
> |
> |  phone: [phone]
> |  <[24]https://urldefense.proofpoint.com/v1/url?u=https://monsi.sso.fran
> |  c
> |  e
> |  t
> |  e
> |  lecom.fr/index.asp?target%3Dhttp%253A%252F%252Fclicvoice.sso.franc
> |  e
> |  t
> |  e
> |  l
> |  ecom.fr%252FClicvoiceV2%252FToolBar.do%253Faction%253Ddefault%2526
> |  r
> |  o
> |  o
> |  t
> |  service%253DSIGNATURE%2526to%253D%26%2343%3B33%25202%252023%252028
> |  %
> |  2
> |  5
> |  2
> |  049%252083%2520&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453y
> |  w
> |  a
> |  G
> |  V
> |  %2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D
> |  %
> |  0
> |  A &
> |  s=4490d282c20720cdbe8d3350c17a191e1762a7ea211ff404be972fddea2f62f3
> |
> |
> |  mobile: [phone]
> |  <[25]https://urldefense.proofpoint.com/v1/url?u=https://monsi.sso.fran
> |  c
> |  e
> |  t
> |  e
> |  lecom.fr/index.asp?target%3Dhttp%253A%252F%252Fclicvoice.sso.franc
> |  e
> |  t
> |  e
> |  l
> |  ecom.fr%252FClicvoiceV2%252FToolBar.do%253Faction%253Ddefault%2526
> |  r
> |  o
> |  o
> |  t
> |  service%253DSIGNATURE%2526to%253D%26%2343%3B33%25206%252037%252086
> |  %
> |  2
> |  5
> |  2
> |  097%252052%2520&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453y
> |  w
> |  a
> |  G
> |  V
> |  %2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D
> |  %
> |  0
> |  A &
> |  s=696fa2cd342bca61fdf5e849c8d3d76abe1075281d4218eaac873227641f9514
> |
> |
> |  [26][e-mail]
> |  <mailto:[e-mail]>
> |
> |
> |
> |
> |
> |  __________________________________________________________________
> |  _ _ _ _ ___________________________________________________
> |
> |  Ce message et ses pieces jointes peuvent contenir des informations
> |  confidentielles ou privilegiees et ne doivent donc pas etre
> |  diffuses, exploites ou copies sans autorisation. Si vous avez recu
> |  ce message par erreur, veuillez le signaler a l'expediteur et le
> |  detruire ainsi que les pieces jointes. Les messages electroniques
> |  etant susceptibles d'alteration, Orange decline toute
> |  responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> |
> |  This message and its attachments may contain confidential or
> |  privileged information that may be protected by law; they should
> |  not be distributed, used or copied without authorisation.
> |  If you have received this email in error, please notify the sender
> |  and delete this message and its attachments.
> |  As emails may be altered, Orange is not liable for messages that
> |  have been modified, changed or falsified.
> |  Thank you.
> |
> |
> |
> |  _______________________________________________
> |  Isis-wg mailing list
> |  [27][e-mail]
> |  [28]https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/ma
> |  i
> |  l
> |  m
> |  a
> |  n/listinfo/isis-wg&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh4
> |  5
> |  3
> |  y
> |  w
> |  aGV%2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U
> |  %
> |  3
> |  D
> |  %
> |  0A&s=3211164dcbc94ec39a7390a5d1c8371f2c391ec0aeec8806884c6abfd4415
> |  1
> |  1
> |  0
> |
> |
> |  ____________________________________________________________________
> |  _ _ _ ___ _______________________________________________
> |
> |  Ce message et ses pieces jointes peuvent contenir des informations
> |  confidentielles ou privilegiees et ne doivent donc pas etre
> |  diffuses, exploites ou copies sans autorisation. Si vous avez recu
> |  ce message par erreur, veuillez le signaler a l'expediteur et le
> |  detruire ainsi que les pieces jointes. Les messages electroniques
> |  etant susceptibles d'alteration, Orange decline toute responsabilite
> |  si ce message a ete altere, deforme ou falsifie. Merci.
> |
> |  This message and its attachments may contain confidential or
> |  privileged information that may be protected by law; they should not
> |  be distributed, used or copied without authorisation.
> |  If you have received this email in error, please notify the sender
> |  and delete this message and its attachments.
> |  As emails may be altered, Orange is not liable for messages that
> |  have been modified, changed or falsified.
> |  Thank you.
> |
> |  _______________________________________________
> |  Isis-wg mailing list
> |  [29][e-mail]
> |  [30]https://www.ietf.org/mailman/listinfo/isis-wg
> |
> |
> |  _____________________________________________________________________
> |  _ _ ___ _______________________________________________
> |
> |  Ce message et ses pieces jointes peuvent contenir des informations
> |  confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> |  exploites ou copies sans autorisation. Si vous avez recu ce message
> |  par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> |  que les pieces jointes. Les messages electroniques etant susceptibles
> |  d'alteration, Orange decline toute responsabilite si ce message a ete
> |  altere, deforme ou falsifie. Merci.
> |
> |  This message and its attachments may contain confidential or
> |  privileged information that may be protected by law; they should not
> |  be distributed, used or copied without authorisation.
> |  If you have received this email in error, please notify the sender
> |  and delete this message and its attachments.
> |  As emails may be altered, Orange is not liable for messages that have
> |  been modified, changed or falsified.
> |  Thank you.
> |
> |
> |
> |  ______________________________________________________________________
> |  _ ___ _______________________________________________
> |
> |  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.
> |
> |  _______________________________________________
> |  Isis-wg mailing list
> |  [31][e-mail]
> |  [32]https://www.ietf.org/mailman/listinfo/isis-wg
> |
> | References
> |
> |    Visible links
> |    1. mailto:[e-mail]
> |    2. mailto:[e-mail]
> |    3. mailto:[e-mail]
> |    4. mailto:[e-mail]
> |    5. mailto:[e-mail]
> |    6. mailto:[e-mail]
> |    7. mailto:[e-mail]
> |    8. mailto:[e-mail]
> |    9. mailto:[e-mail]
> |   10. mailto:[e-mail]
> |   11. mailto:[e-mail]
> |   12. mailto:[e-mail]
> |   13. mailto:[e-mail]
> |   14. mailto:[e-mail]
> |   15. mailto:[e-mail]
> |   16. mailto:[e-mail]
> |   17. mailto:[e-mail]
> |   18. mailto:[e-mail]@orange.com
> |   19. mailto:[e-mail]
> |   20. mailto:[e-mail]
> |   21. mailto:[e-mail]
> |   22. mailto:[e-mail]
> |   23. https://urldefense.proofpoint.com/v1/url?u=http://www.orange.com/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=GJQFPrZyyh453ywaGV%2FvoQ%3D%3D%0A&m=xDbMtpjPKPQ26eNh1Ka%2FhnXOqVfqYtZ9MjolqbbcT8U%3D%0A&s=75085ca9001f9c7a24e6f23efb57f50f5d79a97cbadcbfe1ce65082d335dba35
> |   24. https://urldefense.proofpoint.com/v1/url?u=https://monsi.sso.fran
> |   25. https://urldefense.proofpoint.com/v1/url?u=https://monsi.sso.fran
> |   26. mailto:[e-mail]
> |   27. mailto:[e-mail]
> |   28. https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/ma
> |   29. mailto:[e-mail]
> |   30. https://www.ietf.org/mailman/listinfo/isis-wg
> |   31. mailto:[e-mail]
> |   32. https://www.ietf.org/mailman/listinfo/isis-wg
>
> | _______________________________________________
> | Isis-wg mailing list
> | [e-mail]
> | https://www.ietf.org/mailman/listinfo/isis-wg
>