Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2)

[Igor Bryskin <[e-mail]>]

Deborah,

I am not sure what are you agreeing with. You know me long enough to know that all emails I send on the list are nothing but "technically focused". While you have your "CCAMP Co-Chair hat on" I'd like to communicate with you as the CCAMP Co-Chair.

Yesterday, Lou asked me to take a step back and explain what protocol extensions beyond MELGs we have in mind for the ONTs work. The way I interpreted his request is that he was trying to understand in some depth what exactly we are trying to do. This would be a reasonable request coming, say, from Adrian, but coming from Lou it did sound a bit strange timing-wise because starting from the Paris IETF (March 2012) he's been making statements/guidelines (periodically once in 3-4 months) like the following:
"This is definitely neither BCP nor UNI. ENNI  - this is exactly what you, guys, are doing";
" There are some serious problems with ENNI definitions, so this is not ENNI. VNT/MLN/MRN - isn't this is exactly what you are doing?";
"This is L1VPN Basic mode, Enhanced mode, whatever mode, that's what you are doing";
"I still believe that ONTs or whatever you call it must be built on top of MLN/MRN ".

Also get this: we have not yet finalized the definitions of Virtual Link, Virtual Node, Virtual Topology, Overlay Topology, etc., but the good news is that at least one thing we are certain: whatever definitions we will end up with they will be based on MLN/MRN. This is because Lou told us so (actually, insisted): quite unambiguously, on many occasions both on the list and the face-to-face meeting. This was far stronger than an advice, to me it seemed as a condition on which the work could be progressed in CCAMP. Why is such a bias? Could it be the case, for example, that MLN/MRN, brilliant as it is, defines one "thing" for Virtual Link, while we call VL something totally different? 

After I provided the list of things that IMO need to be solved, I asked Lou to give me pointers/quotes from RFCs that according to Lou have solved already almost each and every problem I identified, and what is needed (also according to Lou) is a bunch of BCPs (Gert, you must love this!). Did I get these quotes? No, not so far. Instead, Lou has chosen to feel offended by my email. Why is that? Did I use a foul language? No. Did I personally attack or humiliate him? No. I did criticize him, though, for a case of WG chair power abuse via bullying the discussion and wasting people's time and asked (quite politely and not for the first time) to stop doing that. That's it. I hope criticizing of an IETF WG chair is a right of an IETF WG member and well within the IETF rules of conduct. The only thing that could be said is that my criticism is unfair. But then again, so far I haven't seen a single email on the list expressing the outrage. Knowing you, I am pretty sure that deep in your heart you agree that there is at least some truth in what I am saying.

Anyway I still hope that I'll get these quotes that I asked.

Cheers,
Igor


-----Original Message-----
From: BRUNGARD, DEBORAH A [mailto:[e-mail]] 
Sent: Wednesday, January 23, 2013 5:42 PM
To: Lou Berger; Igor Bryskin
Cc: CCAMP
Subject: RE: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2)

Agree - please keep the discussion technically focused and avoid any personal comments.

Deborah
(with CCAMP Co-Chair hat on)


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Lou Berger
Sent: Wednesday, January 23, 2013 5:25 PM
To: Igor Bryskin
Cc: CCAMP
Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2)


It seems I failed to make my perspective clear to you in my previous mail. While this may or may not be the case, I believe your mail has moved outside acceptable IETF conduct.

Lou

On 1/23/2013 2:54 PM, Igor Bryskin wrote:
> Please, see in line.
> Igor
> 
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: Wednesday, January 23, 2013 12:48 PM
> To: Igor Bryskin
> Cc: John E Drake; CCAMP; Stewart Bryant; [e-mail]; 'George Swallow (swallow)'
> Subject: RE: Additional overlay protocol extensions? (Was: Re: [CCAMP] 
> Overlay model framework v2)
> 
> Igor,
> 
> See below for responses in line.
> 
> On January 23, 2013 11:42:40 AM Igor Bryskin <[e-mail]> wrote:
>> Lou,
>>
>> Required protocol extensions (just to start with):
>> 1. MELGs +VL's committed/uncommitted status advertising
> 
> Understood, although you and I may not agree on some of the details, but that discussion can wait.
> IB>>Ok
> 
>> 2. Signaling extensions to set correctly client device RSVP timers 
>> and to communicate the state and status of underlying server trail (e.g.
>> taking into account delays due to the server trail setup).
> 
> Isn't this possible with any H-LSP), I.e. not unique to ONTs (or whatever you call it)?
> IB>> Is this covered? Where? We (ADVA, JNPR) had an issue with that and could not find the answer.
> 
> 
>> Issue of RROs: a client device signals the LSP path in terms of 
>> VLs/VNs, what about RROs?;
> 
> How is this a new problem? The issue is present/covered in 4208.
> IB>> 4208 does not have a notion of VL or VN, so it cannot possibly cover it. When ERO is signaled in terms of VLs, how does RRO returned to the client should look like: virtual links? real links? both? encrypted with some key?
> 
>> 3. ONT  OAM extensions and procedures (how to associate DP 
>> alarms/failures happened on real links and nodes with VLs and VNs 
>> that depend on them, so that client LSP restoration could be 
>> controlled by the client?);
> 
> This too seems like a generic problem, I.e., one present in H-LSPs, L1VPNs, and MLN.
> IB>> Where is exactly described how the faults are associated with VLs and VNs? When, say, a fault happens inside a VN, how exactly outside world knows about that to perform an alternative path computation? Please, provide a quote.
> 
>> 4. VN related extensions (do we need to advertise TE RTR TLV on 
>> behalf of a VN, what are the procedures if several real nodes 
>> constitute VN, what is the signaling address to use if a VN is 
>> selected, etc.);
> 
> My understanding of existing RFCs (and discussion) is that virtual nodes/links are advertised just like real nodes/links.  This sounds like an informational, or at most a BCP, document.
> 
> IB>> Disagree. If a VN is comprised of two real nodes handled by separate OSPF speakers, which of them (or both) generate TE RTR TLV on behalf of VN? My solution, for example, is to deprecate completely TE RTR TLV, because it is redundant. In any case, if you know where the issue is covered, please, provide the quote.
> 
>> 5. VN connectivity matrix for addressing VN's blocking/asymmetric 
>> nature, including the detailed connectivity matrix (entries with 
>> associated costs, which will also require signaling extensions: e.g.
>> how to specify in the ERO that a given connectivity matrix entry is 
>> selected?);
> 
> What as a VN connectivity matrix? Does it differ from the connectivity matrix already defined by this group?
> IB>> Yes, it does: the detailed VN connectivity matrix should include a set of costs (in terms of SRLGs, delay, TE matric, etc.) for cross-connecting two interfaces, similar to what Giovanni suggests for OI (optical impairments) vector. The consequence is that there could be more than one entry for the same pair of interfaces, with a consequence of the necessity of signaling extensions. Also, which of the speakers should advertise the connectivity matrix? I have the solution for that which is quite different from the way it is " already defined by this group"
> 
> If yes, it sounds like an extension to the existing work.
> 
> If no, sounds like another informational/BCP.
> 
>> 6. Routing extensions to separate VN's internals from the outside 
>> world;
> 
> Sounds like information exchanged between overlay edge nodes (PEs).  
> Basically the  information that would be needed to support L1VPN enhanced mode.
> IB>> The point of VN as a powerful scalability tool is to present a network to the outside of the world as a single node (i.e. to hide internals) while still exposing in some way an IP connectivity to each of the internal nodes for the management purposes. Considering that VNs can encompass domains made of VNs,  I see this as a big challenge with big benefits if solved. If you know where this issue is covered, please, provide a quote.
> 
>> 7. Access/inter-domain links LMP extensions;
> 
> Isn't this the same as is needed when using rfc5251 or 4208?
> IB>> Access/inter-domain links can be terminated by VNs, so, no, this 
> IB>> is not covered
> 
>> 8. Split-VN specific extensions ( when a blocking real node is 
>> presented via several symmetrical VNs, the VN IDs could be assigned 
>> and changed  automatically (to remove extra configuration burden), 
>> how the client NEs learn that the remote node ID of an access link is
>> (re-)assigned?)
> 
> This is a specific example of item 6 above, right?
> IB>> No. Normally VN requires quite a bit of manual configuration. This is the case when this could be fully automated.
> 
>> 9. Routing extensions to address independent address spaces;
> 
> Part of this is already covered by L1VPN basic mode, and the rest is also required by L1VPN enhanced mode.
> IB>> I am talking about routing extensions for virtual topology which is not part of L1VPN basic mode.
> If this covered for  L1VPN enhanced mode, please, provide the quote as to how this could be handled using OSPF.
> 
>> 10. VPN related extensions: how to advertise VL's association with 
>> one or several VPNs? How to provide VPN-specific VN's connectivity 
>> matrix;
> 
> I think you already covered this above.
> IB>> No, I didn't. I don't know yet how to advertise association of a 
> IB>> VL with one or multiple VPNs, nor how to advertise VPN specific 
> IB>> connectivity matrices, nor how to filter the information from the 
> IB>> users of different VPNs
> 
>> 11. Etc.
>>
>> All of the above mentioned things obviously cannot be done without a 
>> well-understood framework with, yes, tightly defined definitions.
>> Hence the definitions is a very important start.
>>
> 
> Wow that's a long list!
> 
> It seems  to me that a number/most of the items above, can be done as focused and incremental extensions to  existing RFCs/WG products, in a generic way, without any further discussion/agreement on the high level overlay topic. Just like the other (soon to be) new WG documents.
> 
> Certainly the informational/BCP documents would require good understanding of the target use cases.  Given the clear, and seemingly circular, disagreements on basic terminology it might make most sense to spend some time documenting the different use cases/models before continuing the definitions discussion.
> 
> IB>> Lou, as you see I disagreed with pretty much everything you said. 
> IB>> The way I see it, one huge reason why we keep going in circles is 
> IB>> you and your desire to make it look like CCAMP work has a 
> IB>> continuity of developing new things based on existing RFCs. I am 
> IB>> not against continuity when it calls for. This work was not 
> IB>> started because CCAMP WG has initiated it. Let me remind you that 
> IB>> the work has started because we (ADVA and JNPR) have a product 
> IB>> that as we believe could be developed into a wider framework. It 
> IB>> was always meant to be built up as a continuation of RFC4208. I 
> IB>> personally have full respect for this work as well as for what 
> IB>> George is doing to enhance it. What I have problem with is some 
> IB>> CCAMP dead stuff such as MLN/MRN and your contra-productive 
> IB>> attempts to make it look bigger than it is actually worth of. I 
> IB>> also couldn't help but notice that the discussions proceed quite 
> IB>> well until you wake up with your comments, so could you wake up a 
> IB>> bit less frequently?:=)
> 
> Igor (as contributor)
> 
> Lou (as contributor)
> 
>> Cheers,
>> Igor
>>
>> -----Original Message-----
>> From: Lou Berger [mailto:[e-mail]]
>> Sent: Wednesday, January 23, 2013 10:22 AM
>> To: Igor Bryskin
>> Cc: John E Drake; CCAMP; Stewart Bryant; [e-mail]; 'George 
>> Swallow (swallow)'
>> Subject: Additional overlay protocol extensions? (Was: Re: [CCAMP] 
>> Overlay model framework v2)
>>
>>
>>
>> On 1/22/2013 1:58 PM, Igor Bryskin wrote:
>>> ...
>>> Besides, I believe nothing (terminology, architecture,  protocol 
>>> solutions, etc.)  of MLN/MRN is relevant to what we are/were trying 
>>> to achieve with ONTs.
>>>
>>> Igor
>>> ...
>>
>> Igor,
>>
>> Can we take a step back for a moment from the (seemingly endless) 
>> terminology/architecture/framework debate?
>>
>> What additional (i.e., not already covered in a standalone draft, 
>> e.g.,
>> draft-ali-...) *protocol extensions* do you think need to be 
>> standardized (as PS)?
>>
>> Is it more than just MELG?
>>
>> Lou
> 
> 
> 
> 
> 
> 
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp