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

[Igor Bryskin <[e-mail]>]

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 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 VL with one or multiple VPNs, nor how to advertise VPN specific connectivity matrices, nor how to filter the information from the 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. The way I see it, one huge reason why we keep going in circles is you and your desire to make it look like CCAMP work has a continuity of developing new things based on existing RFCs. I am not against continuity when it calls for. This work was not started because CCAMP WG has initiated it. Let me remind you that the work has started because we (ADVA and JNPR) have a product that as we believe could be developed into a wider framework. It was always meant to be built up as a continuation of RFC4208. I personally have full respect for this work as well as for what George is doing to enhance it. What I have problem with is some CCAMP dead stuff such as MLN/MRN and your contra-productive attempts to make it look bigger than it is actually worth of. I also couldn't help but notice that the discussions proceed quite well until you wake up with your comments, so could you wake up a 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