Subject: [Isis-wg] FW: New Version Notification for draft-ginsberg-isis-l2bundles-00.txt

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 6 Jul 2015 20:00:27 +0000

Folks -

A new draft has been submitted. Comments welcome.

   Les

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 06, 2015 12:59 PM
To: Stefano Previdi (sprevidi); cf(mailer list); Mohan Nanduri; Les Ginsberg (ginsberg); Ebben Aries; Stefano Previdi (sprevidi); Les Ginsberg (ginsberg); Mohan Nanduri; cf(mailer list); Ebben Aries
Subject: New Version Notification for draft-ginsberg-isis-l2bundles-00.txt

A new version of I-D, draft-ginsberg-isis-l2bundles-00.txt
has been successfully submitted by Les Ginsberg and posted to the IETF repository.

Name:		draft-ginsberg-isis-l2bundles
Revision:	00
Title:		Advertising L2 Bundle Member Link Attributes in IS-IS
Document date:	2015-07-06
Group:		Individual Submission
Pages:		12
URL:            https://www.ietf.org/internet-drafts/draft-ginsberg-isis-l2bundles-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ginsberg-isis-l2bundles/
Htmlized:       https://tools.ietf.org/html/draft-ginsberg-isis-l2bundles-00

Abstract:
   This document introduces the ability for IS-IS to advertise the link
   attributes of layer 2 (L2) bundle members.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 20 Jul 2015 15:42:10 +0200 (CEST)

> A new draft has been submitted. Comments welcome.

It would be interesting to see text in there how this would interact with 
BFD and/or LACP and ip address configuration.

If I understand correctly, LACP isn't used, IP address isn't configured on 
the individual interfaces? So, BFD can't be used for individual links? 
Where is the IP address configured, just on one of the interfaces?

I have no opinion on the ISIS parts of this, I just don't understand 
operational considerations and I would appreciate (more) text on this 
topic.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: <[email-masked]>
Date: Mon, 20 Jul 2015 14:11:31 +0000

Hi Les,

As I pointed during the session, I would like to see more text regarding the motivation including use cases.
I'm not against the solution (at least now) but I want to be sure about the right solution. I'm a afraid to see that each time with have an issue with L2 bundles because we do not expose the topology, we are adding a fix ... example : BFD microflows ...

For some example of protocol interactions with L3 topology, there are solutions today : LDP using a single TCP session, RSVP-TE has know extensions for ECMP ...
So it would be good to have all the informations consolidated. 

Do you have some plan to have an OSPF companion ? 

Best Regards,

Stephane

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, July 06, 2015 22:00
To: [email-masked] list
Subject: [Isis-wg] FW: New Version Notification for draft-ginsberg-isis-l2bundles-00.txt

Folks -

   Les

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 06, 2015 12:59 PM
To: Stefano Previdi (sprevidi); cf(mailer list); Mohan Nanduri; Les Ginsberg (ginsberg); Ebben Aries; Stefano Previdi (sprevidi); Les Ginsberg (ginsberg); Mohan Nanduri; cf(mailer list); Ebben Aries
Subject: New Version Notification for draft-ginsberg-isis-l2bundles-00.txt

Abstract:

The IETF Secretariat

_______________________________________________
Isis-wg mailing list
[email-masked]
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.

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Mon, 20 Jul 2015 20:52:38 -0700

I presumed that the motivation was clear:
(1) TE and remote health monitor L2 bundle members
     - Able to do TE on individual links
     - Able to remotely monitor the heath of individual member links
(2) Minimal operation impact
     - Do not have to scale up all protocols by a factor of 32, 64,...,
     - Minimal impact of SPF and other core IGP functionality
     - While unnumbered interfaces can be used for P2P links, they are 
more difficult on LAN interfaces and hence requiring significant 
operation overhead to configure and maintain 32, 64 times the number of 
prefixes
(3) Single control protocol with multiple diverse functionalities
     - This is a continuation of the segment routing theme.
     -  We are now able to do some L2 functionality using the same 
control plane protocol

As for the presumption of ability of some protocols to handle ECMP, I 
agree with you but I can think of two risk points
-Making sure that there is no, or at least minimal,  impact on all 
protocols: Assuming that some protocols already have solutions to handle 
the scale up requirement, how much effort (and risk) would it take to go 
over all possible protocols and either make sure there is minimal or no 
impact, or at least come up with 1,2 solutions to mitigate the impact of 
the sudden (and significant) increase in the number of links
- Unnecessary bloat of the routing table, at least on LAN interfaces, 
due to the requirement to configure and maintain additional prefixes

BTW, this solution does not prevent or discourage anyone from using L3 
bundles. The solution is for deployments that want to do TE and remote 
health monitor with minimal risk. L3 bundles (as you mentioned) is still 
a viable solution, but it carries more complexities with it

Thanks

Ahmed

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Mon, 27 Jul 2015 11:08:52 -0700

Hi,

See inline "AB>"

Ahmed

On 7/20/2015 6:42 AM, Mikael Abrahamsson wrote:
> It would be interesting to see text in there how this would interact 
> with BFD and/or LACP and ip address configuration.
AB> All this draft is doing is advertising TE attributes for each 
individual member and adj-SID to allow traffic to be explicitly directed 
towards one or more member links. Nothing more than this:)

>
> If I understand correctly, LACP isn't used, IP address isn't 
> configured on the individual interfaces? So, BFD can't be used for 
> individual links? Where is the IP address configured, just on one of 
> the interfaces?
>

AB> Can you be more specific about the operational considerations?

Ahmed

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 28 Jul 2015 08:14:33 +0200 (CEST)

On Mon, 27 Jul 2015, Ahmed Bashandy (bashandy) wrote:

> AB> All this draft is doing is advertising TE attributes for each individual 
> member and adj-SID to allow traffic to be explicitly directed towards one or 
> more member links. Nothing more than this:)

> AB> Can you be more specific about the operational considerations?

Hm, I re-read the introduction and now I noticed that it actually says 
LACP. I got confused by "L2 bundle" it seems, and the "however" where I 
thought that because this requirement was there, LACP wasn't going to be 
used. Upon re-reading, I see this is all about running LACP *and* then 
advertising the LACP controlled individual links into ISIS.

So may I suggest adding some text:

"However, if there is still a desire to control traffic
    flows on individual physical links,"

replaced by:

"However, if there is still a desire to control traffic
    flows on individual LACP controlled physical links,"

... or something along those lines. It also says "L2 bundle member" which 
for me is a confusing way of saying "individual interface in a bundle", 
which might have added to my confusion.