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

[Lou Berger <[e-mail]>]

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.

> 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)?

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

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

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

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

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.

> 7. Access/inter-domain links LMP extensions;

Isn't this the same as is needed when using rfc5251 or 4208?

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

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

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

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

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