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

[Snigdho Bardalai <[e-mail]>]

There is one use-case I don't see being mentioned - signaling LSPs that are diverse in the provider network and do not have common CE nodes as head-end or tail-end.

I believe this will require some extensions, not sure what yet!!

Regards
Snigdho

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Lou Berger
> Sent: Wednesday, January 23, 2013 9:48 AM
> To: Igor Bryskin
> Cc: CCAMP
> Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re:
> 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.
> 
> > 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
> 
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp