Re: [mpls] [Teas] [Rtg-yang-coord] Generic LSP Yang

[Igor Bryskin <[e-mail]>]

Hi guys,

Robert, your interpretation is spot on. Considering the context (the statement was made in response to Druv's email) I don't see how it could be read differently.

LSP model defines how we configure, manipulate an LSP, interpret its parameters, stuff like that. This means the management and control planes.
It is important to keep in perspective why do we do this modelling in IETF. In his presentation on MPLS/SDN 2014 conference Kireeti said that in MPLS networks we have achieved full interoperability in data plane and sufficient one in control plane. The problem and perpetual pain for operators is that each vendor exposes very different interfaces and tools to configure and manage the services. Contemporary management protocols like NETCONF in conjunction with standardized models will solve this.
 However, we do not attempt to (re-)model the data plane, right?

Cheers
Igor
________________________________________
From: mpls [[e-mail]] on behalf of Robert Raszuk [[e-mail]]
Sent: Sunday, March 8, 2015 6:58 AM
To: Loa Andersson
Cc: [e-mail]; [e-mail]
Subject: Re: [mpls] [Teas]  [Rtg-yang-coord] Generic LSP Yang

Hi Loa,

The way I read Igor statement and agreed with it in a sense of "nothing in common" was that it was referring to the control plane.

The subject of this thread is "Generic LSP YANG" and to me Yang model describes control aspect of protocol or functionality not the choice of forwarding header in the data plane.

So if you and others agree we should be all in sync and perhaps we could consider as proposed before Generic Engineered Path model branching at the lower layer between unicast and multicast.

However if you still think that Yang is about data plane and OAM then perhaps we have a bigger issue here ....

Cheers,
R.




On Sun, Mar 8, 2015 at 10:27 AM, Loa Andersson <[e-mail]<mailto:[e-mail]>> wrote:
Himanshu, et.al<http://et.al>.,

I think there are two issues here and if sorting them out corrrectly
we are very close.

The first issue is similarities between different types of LSPs.

Here I said that, at least for a MPLS PSN, there are similarities,
e.g. the data plane is (nearly) the same. This was said in reaction
to Igor's statement "IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing
in common." I still don't think that Igor's statement is really correct.
If he had said "IMHO there are not enough similarites between TE-LSP,
LDP-LSP and SPRING-LSP to motivate a common model". I think that we be
a much more accurate statement.

And that is the other issue - Is it reasonable to model TE-LSP,
LDP-LSP and SPRING-LSP in the same model? I don't not think it is,
but that we need an overlap of people working with the different models.

Hope this is clear enough.

/Loa


On 2015-03-07 23:19, Shah, Himanshu wrote:
/I agree with Robert and Igor, putting everything in the same bucket
because of common data plane & OAM does not justify./

/We wouldn’t consider doing same for IP data plane../

/I think we need to separate these models and as mentioned earlier,
there is already work going on in respective WGs./

//

/Thanks,/

/himanshu/

//

//

//

*From:*mpls [mailto:[e-mail]<mailto:[e-mail]>] *On Behalf Of *Loa Andersson
*Sent:* Saturday, March 07, 2015 8:18 AM
*To:* [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>
*Subject:* Re: [mpls] [Rtg-yang-coord] [Teas] Generic LSP Yang

Robert,

 From one perspective I agree with you and Igor, however if you think
about MPLS LSPs, from a data plane perspective - and that is where OAM
operates, there almost no difference between a TE-LSP a LDP-LSP and a
SPRING MPLS LSP come very close.

If you the other hand think of LSPs for other data planes the "nothing
in common" is an almost true statement. From that point of view I think
different models are where we will end up, but I also think that we need
"separation with moderation".

  But nothing is so simple that we can capture it in one very simple
statement, we have hacking away on this for 30 years now, I'd advice
taking architecture and history into consideration, as well as viewing
the sky from a different perspective than from the bottom of a deep well.

Let me also say that I'm very supportive of all the good work going on
in this area.

/Loa

Sent from my iPad


On 07 Mar 2015, at 19:47, Robert Raszuk <[e-mail]<mailto:[e-mail]>
<mailto:[e-mail]<mailto:[e-mail]>>> wrote:

    I would agree with Igor.

    Other then name overlap those are completely different technologies
    and artificially putting them under "LSP" umbrella just does not
    bring any value, but only confuses things even more.

    Q: What SPRING-LSP has anything in common with "label" when you use
    v6 header ?

    If you want to search for some commonalities let's remove LDP-LSPs
    from this mix (as the is not relevant) and leave TE-LSP & SPRING +
    maybe also add BIER as well as change the name to Generic-EP
    (Engineered Paths).

    I see no value of goruping based on the fact that data plane uses
    mpls labels, but rather I would see reasonable to provide models
    based on the transport path characteristics for the traffic it is to
    carry.

    Best,

    r.

    On Fri, Mar 6, 2015 at 2:11 PM, Igor Bryskin
    <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> wrote:

    Druv,

    IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common. They
    should have totally independent models each being developed in
    respective WG.

    Igor

    _______________________________________________
    Rtg-yang-coord mailing list
    [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
    https://www.ietf.org/mailman/listinfo/rtg-yang-coord



_______________________________________________
Teas mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teas


--


Loa Andersson                        email: [e-mail]<mailto:[e-mail]>
Senior MPLS Expert                          [e-mail]<mailto:[e-mail]>
Huawei Technologies (consultant)     phone: [phone]<tel:%2B46%20739%2081%2021%2064>