The MPLS WG Archive

[darren.freeland@bt.com]

Hi Kireeti,

> Could you clarify what you mean by "IP-centric control protocols":
> a) IP control protocols (such as OSPF, RSVP, CR-LDP), or
> b) control protocols aimed at serving an IP infrastructure?

I mean (a) - questioning the assumption that these will be used for the OTN
control plane.  I think it makes sense to fully consider OTN requirements
before we decide upon which protocols will best meet these requirements.  I
don't believe that operators requirements have been discussed enough here to
justify the assumption of (a) for the OTN.  Note that I would also be
questioning this if people were working on extensions to any other
particular set of control protocols, without working to an agreed set of
requirements! 

> Why I ask the above question is that there is a UNI based on IP
> control protocols (draft-gray-mpls-rsvp-oif-uni-ext-00.txt), which
> caters to non-IP uses of the OTN, and whose underlying model is the
> overlay model.  This draft is in response to the *OIF*'s requirements
> for an optical UNI.

I was not aware of this ID.  Thanks.  I will have a look at it when I'm back
in the office Monday morning.

> However, if your objection is to the use of IP control protocols,
> that's a different issue.  Note that the IETF is unlikely to be the
> right venue for discussing say PNNI as a control plane for the OTN.

I am not objecting to the use of any particular control protocols ... yet.
My point is that we have to have more discussion on operators requirements
before we can decide.

> For what it's worth, the MPLS control plane is IP-based, but serves
> non-IP uses quite well.  There is an upcoming foo-over-MPLS BOF that
> illustrates this point.

I read the draft - looking forward to the BOF :)

> That hardly matters.  If it makes sense to service providers, the
> vendors will come around :-)

Thanks for the encouragement.  I think I've made my point for now.  I would
like to hear (on the list) opinions from other vendors though.  Otherwise,
I'll keep quite(ish) until I have an ID to contribute :)

> One thing though is to better articulate what is broken with the
> current approach.  If it's not the "peer vs. overlay" model that's
> the issue, then like you say, I've missed your point, and would
> like to understand what the real problem is.

My first concern is as discussed above.  My second is the validity of the
peer model for an operator such as ourselves with multi-client requirements.
I have noted the proposal highlighted by John Drake that we could have an
overlay based model at the UNI, and a peer based one at the NNI.  This is
something I have to consider in more detail.  I am still not convinced on
common addressing across client and server layers ('server layer trails =
client layer links').  If someone can convince me otherwise, I'm willing to
listen.

Have a good weekend.

Darren.