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

[Hannes Gredler <[e-mail]>]

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

- there is no receive side component in your draft -
  i.e. IS-IS is used only as a northbound protocol

- 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.

- there are some concerns to bloat the IGP (which does topology
  discovery) with non routing related functions.

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.

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