Subject: [mpls] Questions on seamless MPLS

From: Javier Jimenez <[email-masked]>
Date: Fri, 01 Apr 2011 15:56:41 +0200

Hi all,

Here in Telefónica we are pushing for MPLS E2E solutions, and it seems
the seamless MPLS draft respresents a great starting point.
Congratulations to the authors for this nice piece of work.

I have two questions, not being involved in the draft so far:
1.- The draft proposes to use the next-hop-self in the outwards
direction (with respect to an specific regional area) and to leave
next-hop-unchanged for the incoming traffic. This approach requires that
some routing information is flooded from the core area to the regional
ones (specificallly, reachability to the ABRs). I'm sure this design
increases the scalability of the solution, but two concerns come to my mind:
- Wouldn't it be cleaner to perform the next-hop-self in both
directions? I come from the transport world, where things tend to be
symetrical (and easier to understand for humans).
- More specifically, when migrating to a seamless architecture, it may
be the case that the IGPs are already different in the core and in the
regions (also the label distribution protocols), and it could not be
possible to flood external IGP information into the regional areas or
the operator would prefer to keep IGP clear from external influece (for
that reason you have BGP).
In summary, would there be room for two options (and which are the pros
& cons) or just the one recommended in the draft?

2.- Right now, VPLS services are typically offered only on a regional
basis due to scalability issues. How would a VPLS service scale on top
of a seamless MPLS architecture? Is this requirement part of the
architecture or has been intentionally removed?

Kind regards,
Javier Jimenez
Telefónica Research

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Sat, 2 Apr 2011 09:58:32 +0100

Chris,

Totally agree.

Yaakov,

I haven't read draft-leymann-mpls-seamless-mpls-03 in its entirety but I did read the security considerations section and my interpretation was that that statement you quote, and the sentence that follows, i.e.

   Nevertheless the unauthorized access to such in device
   SHOULD NOT impose any security risks to the MPLS infrastructure
   itself.  Seamless MPLS must be stable regarding attacks against
   access and aggregation nodes running MPLS.

Is not making a claim that there are no security risks in that deployment model but rather is stating a requirement that the architecture/etc SHOULD consider the security risks and minimise them.

The security considerations section is rather short and I interpreted the text in there as introductory text which is preamble to the identified sub-sctions that are currently marked TBD.

Assuming my interpretation is correct (and I am sure the draft's authors can confirm/deny that) then the question I guess is whether you feel that further text needs to be developed before adopting the draft as a WG document or whether that can done by the WG after the draft is adopted?

Ben

On 29 Mar 2011, at 21:45, Christopher LILJENSTOLPE wrote:

> Greetings,
> 
> Let me second this set of concerns.  In an SP network, I can elect not to extend my IGP into uncontrolled spaces, and, instead use control plane protocols that I can apply policy to (BGP comes to mind).  The document does talk about hierarchy, and using BGP to distribute labels (anyone care to think about the number of non-aggregateable labels in a large network that BGP would have to distribute, btw?).  However, there is no mention of the security implications of defining the correct (or incorrect) aggregation/protocol boundary.  
> 
> In the not too distant future, some lazy operator decides that statics are too hard, and extends the IGP down to the access nodes (which are not physically controlled - may even be on customer prem) - Customer does some "research" and injects routes into said IGP after circumventing default passwords - sit back and watch the fun and fireworks.   Anyone who says that the service provider won't be lazy and/or won't deploy with default or well-known passwords - I have MANY cases to prove otherwise....
> 
> If we think this work is valid, then we REALLY need to cover this in detail in the architecture and security sections.  I am not, however, indicating that I do think it is a good idea....
> 
> Chris
> 
> On 30Mar2011, at 03.09, Yaakov Stein wrote:
> 
>> That is not quite the kind of attack I was worried about.
>> 
>> Someone able to inject packets into an MPLS network
>> can wreak more havoc than a monster truck.
>> 
>> Y(J)S
>> 
>> From: Mallette, Edwin [mailto:[email-masked]]
>> Sent: Tuesday, March 29, 2011 18:53
>> To: Yaakov Stein; [email-masked]
>> Subject: Re: [mpls] seamless MPLS
>> 
>> This made me laugh, but I'm going to go out on a limb here and say the type of access meant was physical access.   For instance, if I take out my monster truck and physically access said DSLAM by running over the street cabinet that wouldn't have any real risk to the MPLS infrastructure - just to the DSLAM.  But a slightly modified wording might help.
>> 
>> Ed
>> 
>> From: Yaakov Stein <[email-masked]<mailto:[email-masked]>>
>> Date: Tue, 29 Mar 2011 11:44:24 -0400
>> To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
>> Subject: [mpls] seamless MPLS
>> 
>> Before draft-leymann-mpls-seamless-mpls-03 is moved to become a WG draft,
>> I would like to clarify  the security implications.
>> 
>> The security section of this draft starts very well :
>> 
>>   In a typical MPLS deployment the use of MPLS is limited to relatively
>>   small network consisting of core and edge nodes.  Those nodes are
>>   under full control of the services provider and placed at locations
>>   where only authorized personal has access (this also includes
>>   physical access to the nodes).  With the extensions of MPLS towards
>>   access and aggregation nodes not all nodes will be "locked away" in
>>   secure locations.  Small access nodes like DSLAMs will be located in
>>   street cabinets, potentially offering access to the "interested
>>   researcher".
>> 
>> I couldn't have stated this any better myself.
>> However it then goes on to say :
>> 
>>                 Nevertheless the unauthorized access to such in device
>>   SHOULD NOT impose any security risks to the MPLS infrastructure
>>   itself.
>> 
>> I would love to hear the reasoning behind this statement.
>> 
>> Y(J)S
>> 
>> 
>> ________________________________
>> CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it.
>> _______________________________________________
>> mpls mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls
> 
> ---
> 李柯睿
> Check my PGP key here:
> https://www.asgaard.org/~cdl/cdl.asc
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Sat, 2 Apr 2011 13:06:06 +0200

In-line

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Javier Jimenez
Sent: vrijdag 1 april 2011 15:57
Cc: [email-masked]
Subject: [mpls] Questions on seamless MPLS

Hi all,

WH> when you perform NH self you will install a LBL entry for every LBL prefix and would result in a bigger LFIB.

WH> the reason of the current architecture is due to scalability as outlined above

WH> VPLS scale is orthogonal of the seamless MPLS architecture and it depends on the MAC@, replication/P2MP LSP architecture, end-points, use of H-VPLS, etc. Seamless MPLS is not changing these parameters for VPLS services, VPLS will just use the seamless MPLS architecture

Kind regards,
Javier Jimenez
Telefónica Research

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 3 Apr 2011 13:02:16 +0000

Ben

I believe that we need some plausible explanation on how the security issues
detailed in section 4.2 of RFC 5920 can be addressed,
before considering this technique.

The IETF spent an enormous effort to ensure that MPLS-TP would not break existing MPLS networks, 
even when interconnection of TP and non-TP networks was not being considered. 

Here is a method designed precisely to interconnect existing networks with ones of dubious security.
It wouldn't make sense to adopt this as a WG draft without hearing how this won't bring down
all of our existing networks. 

RFC 5920 section 5.3 suggests solutions, such as the use of firewalls.
Were strong mandatory data-plane access control mechanisms spelled out in this document,
then I would have no objection to adopting it as a WG draft.

Y(J)S

-----Original Message-----
From: Benjamin Niven-Jenkins [mailto:[email-masked]] 
Sent: Saturday, April 02, 2011 11:59
To: Christopher LILJENSTOLPE
Cc: Yaakov Stein; [email-masked]; Mallette, Edwin
Subject: Re: [mpls] seamless MPLS

Chris,

Totally agree.

Yaakov,

Ben

---

From: <[email-masked]>
Date: Sun, 3 Apr 2011 21:36:33 +0200

Javier,

see in line (TB)

Thomas

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Henderickx, Wim (Wim)
> Sent: Saturday, April 02, 2011 1:06 PM
> To: Javier Jimenez
> Cc: [email-masked]
> Subject: Re: [mpls] Questions on seamless MPLS
>
> In-line
>
> WH> when you perform NH self you will install a LBL entry for
> every LBL prefix and would result in a bigger LFIB.
>

TB> we had exaclty this discussion regarding a next hop self (NHS) for incomming traffic. In an single IGP scenario, the NHS is not required (in our discussion, symmetry was also a topic - but we are neigher physicists nor transport people). So we decided to avoid it because of scalability reasons as Wim explained. But there are certain scenarios, where a NHS for incomming traffic is preferred or required.

> WH> VPLS scale is orthogonal of the seamless MPLS
> architecture and it depends on the MAC@, replication/P2MP LSP
> architecture, end-points, use of H-VPLS, etc. Seamless MPLS
> is not changing these parameters for VPLS services, VPLS will
> just use the seamless MPLS architecture

TB> With the Seamless-MPLS approach, we consider different VPLS scenarios: H-VPLS, flat VPLS or also a combination of PW based backhaul to a VSI on a central PE (section 10.1.3 of rfc4762). This does not fix the scalability problem of Ethernet, but provide some possible solutions (e.g. easy backhauling to a high scaling PE).

>
> Kind regards,
> Javier Jimenez
> Telefónica Research
>
> Este mensaje se dirige exclusivamente a su destinatario.
> Puede consultar nuestra política de envío y recepción de
> correo electrónico en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We
> only send and receive email on the basis of the terms set out at.

---

From: Javier Jimenez <[email-masked]>
Date: Tue, 12 Apr 2011 19:02:41 +0200

Hi Thomas, Wim,

Thanks for your responses.

Some additional thoughts:

Right, but that only makes a difference if a small set of inter-domain
LSPs is expected (which may be true). As this number grows, the
difference in scalability will eventually dissapear, right?

Anyway, it might be interesting for operators that are already running
metro MPLS networks to keep separated IGP / LDP instances in different
domains. In this case either we allow next hop self in both directions
or we need to redistribute routes among IGPs, etc. If the intention is
to make a generalistic recommendation, wouldn't it make sense to show
the different options and then leave the final decision to the operator?

On the other side, after reading the draft, I'm not sure why it is
claimed that only those labels needed to support the actual services in
place need to be installed in the AGN nodes. Is this the default
behaviour? I would assume that all the labels distributed in BGP would
be installed in all the AGNs automatically, but I may be wrong. I'm not
sure it is explained in the text why this happens.

I agree with the fact that VPLS is an orthogonal problem, but I noticed
that is was not mentioned in the draft (while point to point business
services are indeed) and I was wondering if it was intentional.
Otherwise, I would include this service as part of the reference
scenarios, so that any potential implication may arise more easily.

Finally, and regarding the OAM, the question is: does the seamless MPLS
architecture consider MPLS-TP OAM to any extent? If so, it should be
stated in the text.

Kind regards,
Javier

El 03/04/2011 21:36, [email-masked] escribió:
>> Behalf Of Javier Jimenez
> .

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Wed, 13 Apr 2011 15:43:46 +0200

Javier, in-line with WH2

-----Original Message-----
From: Javier Jimenez [mailto:[email-masked]] 
Sent: dinsdag 12 april 2011 19:03
To: [email-masked]
Cc: [email-masked]; Henderickx, Wim (Wim)
Subject: Re: [mpls] Questions on seamless MPLS

Hi Thomas, Wim,

WH2> we will include some text on the consequences of one or the other architecture

WH2> there is no intention to include MPLS-TP OAM in the draft

Kind regards,
Javier