Subject: [spring] draft-gredler-spring-mpls-05.txt as SPRING WG document

From: Yakov Rekhter <[email-masked]>
Date: Fri, 16 May 2014 10:37:47 -0700

Alvaro and John,

The authors of draft-gredler-spring-mpls-05.txt would like
to ask SPRING WG to accept this draft as SPRING WG document.

Yakov.
------- Forwarded Message

Date:    Fri, 16 May 2014 10:33:51 -0700
From:    <[email-masked]>
To:      <[email-masked]>
Subject: I-D Action: draft-gredler-spring-mpls-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Supporting Source/Explicitly Routed Tunnels via Stack
ed LSPs
        Authors         : Hannes Gredler
                          Yakov Rekhter
                          Luay Jalil
                          Sriganesh Kini
                          Xiaohu Xu
	Filename        : draft-gredler-spring-mpls-05.txt
	Pages           : 17
	Date            : 2014-05-16

Abstract:
   This document describes how source/explicitly routed tunnels could be
   realized using stacked Label Switched Paths (LSPs).

   This document also describes how use of IS-IS/OSPF as a label
   distribution protocol fits into the MPLS architecture.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-gredler-spring-mpls/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-gredler-spring-mpls-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-gredler-spring-mpls-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

------- End of Forwarded Message

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 16 May 2014 20:21:38 +0200

Hi,

Two comments on this document.

Question:

Assume there is label binding received for a given FEC from/by
multiple protocols. Which one should be chosen by the LSR to be used
in data plane? Choosing wrong one may jeoparadise the hope of
stitching.

Is consistent manual configuration across multiple LSRs an answer ?

If so document should mention that. Otherwise analogy of admin
distance for FECs should be proposed.

Example: Is FEC distributed by OSPF more important then FEC
distributed by targetted LDP session in the same OSPF domain ?

On the other hand if this case is considered an error a corresponding
error handling section may be required.

Recommendation:

s/distirbution/distribution/

Best regards,
R.

On Fri, May 16, 2014 at 7:37 PM, Yakov Rekhter <[email-masked]> wrote:
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 19 May 2014 11:40:35 -0700

Robert,

> error handling section may be required.

When a router obtains label binding for a given FEC from more than
one label distribution protocol (e.g., one binding from targeted LDP
and another from IS-IS/OSPF), deciding which label binding to use
is a matter of policy local to the router. Use of the administrative
distance is an instance of such policy.

In the scenario where a router obtains label binding for a given FEC 
from both targeted LDP and IS-IS/OSPF, one could argue that a reasonable
default behavior would be to prefer the one obtained from targeted LDP.

> s/distirbution/distribution/

Will fix in the next version.

Thanks.

Yakov.

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 20 May 2014 17:18:56 +0200

hi robert,

On Fri, May 16, 2014 at 08:21:38PM +0200, Robert Raszuk wrote:
| Hi,
| 
| Two comments on this document.
| 
| 
| Question:
| 
| Assume there is label binding received for a given FEC from/by
| multiple protocols. Which one should be chosen by the LSR to be used
| in data plane? Choosing wrong one may jeoparadise the hope of
| stitching.

i'd assume that an implementation supporting multiple label-distribution protocols,
has an internal tie-breaking scheme and install LSPs for a fiven FEC only from
the highest ranking protocol.

| Is consistent manual configuration across multiple LSRs an answer ?

possibly; - see below;
 
| If so document should mention that. Otherwise analogy of admin
| distance for FECs should be proposed.

explicitly mentioning that there is a plurality of label-binding protocols
seems unecessary to me. you are right insofar as rfc3031 does *not* mention
a tie-breaking amon protocols and yet there are implemntations who support
more than one concurrent label-distribution protocol.
 
| Example: Is FEC distributed by OSPF more important then FEC
| distributed by targetted LDP session in the same OSPF domain ?

that is an implementation choice; hopefully the administrative
preference is user configurable.

| On the other hand if this case is considered an error a corresponding
| error handling section may be required.
| 
| 
| Recommendation:
| 
| s/distirbution/distribution/
| 
| 
| Best regards,
| R.
| 
| 
| On Fri, May 16, 2014 at 7:37 PM, Yakov Rekhter <[email-masked]> wrote:
| > Alvaro and John,
| >
| > The authors of draft-gredler-spring-mpls-05.txt would like
| > to ask SPRING WG to accept this draft as SPRING WG document.
| >
| > Yakov.
| > ------- Forwarded Message
| >
| > Date:    Fri, 16 May 2014 10:33:51 -0700
| > From:    <[email-masked]>
| > To:      <[email-masked]>
| > Subject: I-D Action: draft-gredler-spring-mpls-05.txt
| >
| >
| > A New Internet-Draft is available from the on-line Internet-Drafts directories.
| >
| >
| >         Title           : Supporting Source/Explicitly Routed Tunnels via Stack
| > ed LSPs
| >         Authors         : Hannes Gredler
| >                           Yakov Rekhter
| >                           Luay Jalil
| >                           Sriganesh Kini
| >                           Xiaohu Xu
| >         Filename        : draft-gredler-spring-mpls-05.txt
| >         Pages           : 17
| >         Date            : 2014-05-16
| >
| > Abstract:
| >    This document describes how source/explicitly routed tunnels could be
| >    realized using stacked Label Switched Paths (LSPs).
| >
| >    This document also describes how use of IS-IS/OSPF as a label
| >    distribution protocol fits into the MPLS architecture.
| >
| >
| > The IETF datatracker status page for this draft is:
| > https://datatracker.ietf.org/doc/draft-gredler-spring-mpls/
| >
| > There's also a htmlized version available at:
| > http://tools.ietf.org/html/draft-gredler-spring-mpls-05
| >
| > A diff from the previous version is available at:
| > http://www.ietf.org/rfcdiff?url2=draft-gredler-spring-mpls-05
| >
| >
| > Please note that it may take a couple of minutes from the time of submission
| > until the htmlized version and diff are available at tools.ietf.org.
| >
| > Internet-Drafts are also available by anonymous FTP at:
| > ftp://ftp.ietf.org/internet-drafts/
| >
| > _______________________________________________
| > I-D-Announce mailing list
| > [email-masked]
| > https://www.ietf.org/mailman/listinfo/i-d-announce
| > Internet-Draft directories: http://www.ietf.org/shadow.html
| > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
| >
| > ------- End of Forwarded Message
| >
| > _______________________________________________
| > spring mailing list
| > [email-masked]
| > https://www.ietf.org/mailman/listinfo/spring
| 
| _______________________________________________
| spring mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/spring

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 20 May 2014 17:26:59 +0200

Hi Hannes & Yakov,

Thank you for your opinion on this.

My major concern is consistency among routers especially in large network.

While indeed one may say that this is a local policy matter the
question is can we do better then that especially where we are coming
with new label distribution protocols.

Also implementations need to somehow define such policy and perhaps
setting a reference to a recommended order in RFC could be a good set
of defaults ?

Otherwise likely Murphy's law will apply :)

Cheers,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 21 May 2014 07:18:39 +0000

Hi Robert,

> -----邮件原件-----
> 发件人: spring [mailto:[email-masked]] 代表 Robert Raszuk
> 发送时间: 2014年5月20日 23:27
> 收件人: Hannes Gredler
> 抄送: Yakov Rekhter; [email-masked]; John G. Scudder; Alvaro Retana (aretana)
> 主题: Re: [spring] draft-gredler-spring-mpls-05.txt as SPRING WG document
> 
> Hi Hannes & Yakov,
> 

Since there are just label distribution protocols which don't affect the route selection at all, why do you care about that consistency among routers? 

Best regards,
Xiaohu

> While indeed one may say that this is a local policy matter the question is can we
> do better then that especially where we are coming with new label distribution
> protocols.
> 
> Also implementations need to somehow define such policy and perhaps setting a
> reference to a recommended order in RFC could be a good set of defaults ?
> 
> > i'd assume that an implementation supporting multiple
> > label-distribution protocols, has an internal tie-breaking scheme and
> > install LSPs for a fiven FEC only from the highest ranking protocol.
> >
> > explicitly mentioning that there is a plurality of label-binding
> > protocols seems unecessary to me. you are right insofar as rfc3031
> > does *not* mention a tie-breaking amon protocols and yet there are
> > implemntations who support more than one concurrent label-distribution
> protocol.
> >
> > | On the other hand if this case is considered an error a
> > | corresponding error handling section may be required.
> > |
> > |
> > | Recommendation:
> > |
> > | > The authors of draft-gredler-spring-mpls-05.txt would like to ask
> > | > SPRING WG to accept this draft as SPRING WG document.
> > | >
> > | > Yakov.
> > | > Please note that it may take a couple of minutes from the time of
> > | > submission until the htmlized version and diff are available at tools.ietf.org.
> > | >
> > | > Internet-Draft directories: http://www.ietf.org/shadow.html or
> > | > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > | >

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 May 2014 09:25:10 +0200

Xiaohu,

> Since there are just label distribution protocols which don't affect the route
> selection at all, why do you care about that consistency among routers?

We are talking about label selection and not route selection.

This is about the same FEC so same route hence route selection does
not come to the picture.

Thx,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 21 May 2014 07:33:44 +0000

Robert,

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Robert Raszuk
> 发送时间: 2014年5月21日 15:25
> 收件人: Xuxiaohu
> 抄送: Hannes Gredler; Yakov Rekhter; [email-masked]; Alvaro Retana (aretana);
> John G. Scudder
> > Since there are just label distribution protocols which don't affect
> > the route selection at all, why do you care about that consistency among
> routers?
> 
> This is about the same FEC so same route hence route selection does not come to
> the picture.

Sure. Then what's the problem if there is inconsistency of label selection among routers (e.g., some routers prefer label bindings learnt from ISIS while others prefer label bindings learnt from LDP)?

Best regards,
Xiaohu

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 May 2014 09:40:53 +0200

If your SR segments are to be engineered by set of SR headers for a
given FEC and anywhere in the network you will suddenly choose LDP
learned label for a given FEC the forwarding results will be rather
poor don't you think ?

r.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 21 May 2014 08:01:06 +0000

No, I don't think so. As long as a label for a given 32/ or 128/ FEC is attached to a packet, no matter from whichever label distribution protocol this label is learnt, the packet would definitely be forwarded to the node identified by that FEC along the shortest path.

Could you give a concrete example to illustrate why the forwarding result is rather poor?

Best regards,
Xiaohu

> 发送时间: 2014年5月21日 15:41
> 抄送: Hannes Gredler; [email-masked]; Alvaro Retana (aretana); John G.
> Scudder; Yakov Rekhter
> 主题: Re: [spring] 答复: draft-gredler-spring-mpls-05.txt as SPRING WG
> document
> 
> If your SR segments are to be engineered by set of SR headers for a given FEC
> and anywhere in the network you will suddenly choose LDP learned label for a
> given FEC the forwarding results will be rather poor don't you think ?
> 
> r.
> 
> >> 抄送: Hannes Gredler; Yakov Rekhter; [email-masked]; Alvaro Retana
> >> (aretana); John G. Scudder
> >> > Since there are just label distribution protocols which don't
> >> > affect the route selection at all, why do you care about that
> >> > consistency among
> >> routers?
> >>
> > Sure. Then what's the problem if there is inconsistency of label selection
> among routers (e.g., some routers prefer label bindings learnt from ISIS while
> others prefer label bindings learnt from LDP)?
> >
> > Best regards,
> > Xiaohu
> >
> >> Thx,
> >> R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 May 2014 10:11:45 +0200

Xu,

You do not get the concept of global (domian wide) label.

You can't attach to a packet SR header with labels (SIDs) learned by
ISIS and in the segment nodes use LDP learned labels for forwarding in
your data plane.

That's the issue with consistency of label for a given FEC distributed
by more then one protocol within your domain.

Best,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 21 May 2014 08:38:18 +0000

> 发送时间: 2014年5月21日 16:12
> 抄送: Yakov Rekhter; Hannes Gredler; [email-masked]; John G. Scudder; Alvaro
> Retana (aretana)
> 主题: Re: [spring] 答复: 答复: draft-gredler-spring-mpls-05.txt as SPRING WG
> document
> 
> Xu,
> 

Maybe. 

> You can't attach to a packet SR header with labels (SIDs) learned by ISIS and in
> the segment nodes use LDP learned labels for forwarding in your data plane.

Why can't? Please give a CONCRETE example and then assert who don’t get the concept of MPLS and SR:)

Best regards,
Xiaohu

> That's the issue with consistency of label for a given FEC distributed by more
> then one protocol within your domain.
> 
> Best,
> R.
> 
> > No, I don't think so. As long as a label for a given 32/ or 128/ FEC is attached to
> a packet, no matter from whichever label distribution protocol this label is learnt,
> the packet would definitely be forwarded to the node identified by that FEC
> along the shortest path.
> >
> >> learned label for a given FEC the forwarding results will be rather poor don't
> you think ?
> >>
> >> r.
> >>
> >> >> This is about the same FEC so same route hence route selection
> >> >> does not come to the picture.
> >> >
> >> among routers (e.g., some routers prefer label bindings learnt from
> >> ISIS while others prefer label bindings learnt from LDP)?
> >> >
> >> > Best regards,
> >> > Xiaohu
> >> >
> >> >> Thx,
> >> >> R.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 21 May 2014 13:07:17 +0000

Robert,

> Otherwise likely Murphy's law will apply :)

How about if I'll add the following to the draft:

   When a router obtains label binding for a given FEC from more than
   one label distribution protocol (e.g., one binding from targeted LDP
   and another from IS-IS/OSPF), deciding which label binding to use
   is a matter of policy local to the router.

   In the scenario where a router obtains label binding for a given FEC
   from both (targeted) LDP and IS-IS/OSPF, the default behavior
   RECOMMENDED in this document is to prefer the one obtained
   from (targeted) LDP. An implementation MUST support the
   ability to override the default behavior via configuration.

Yakov.

> > implemntations who support more than one concurrent label-
> distribution protocol.
> >

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 May 2014 15:45:18 +0200

Hi Yakov,

Yes IMO this would be good addition.

As to the default example perhaps it would be good to make it complete
in a sense of adding label-bgp. We could say:

   In the scenario where a router obtains label binding for a given FEC
   from all (targeted) LDP, Label-BGP and IS-IS/OSPF, the default behavior
   RECOMMENDED in this document is to prefer the one obtained
   from (targeted) LDP followed by ISIS-OSPF one. An implementation
   MUST support the ability to override the default behavior via configuration.

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 May 2014 16:07:30 +0200

Hi Xu,

Sure .. please see attached CONCRETE example.

Best,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 22 May 2014 01:27:59 +0000

Hi Robert,

On R2, the label 33 learnt from T-LDP should be the outgoing label, rather than the ingoing label for FEC 3.3.3.3/32, one of the incoming labels for FEC 3.3.3.3/32 should be 1033. Another incoming label for FEC 3.3.3.3/32 is a label (e.g., 44) allocated by the LDP module. In other word, when receiving a packet with top label of either 1033 or 44, that top label would be swapped to 33.

Best regards,
Xiaohu

> 发送时间: 2014年5月21日 22:08
> 抄送: Yakov Rekhter; [email-masked]; Hannes Gredler; John G. Scudder; Alvaro
> Retana (aretana)
> 主题: Re: [spring] 答复: 答复: 答复: draft-gredler-spring-mpls-05.txt as
> SPRING WG document
> 
> Hi Xu,
> 
> >> 抄送: Yakov Rekhter; Hannes Gredler; [email-masked]; John G. Scudder;
> >> Alvaro Retana (aretana)
> >> 主题: Re: [spring] 答复: 答复: draft-gredler-spring-mpls-05.txt as SPRING
> >> WG document
> >>
> >> Xu,
> >>
> >> ISIS and in the segment nodes use LDP learned labels for forwarding in your
> data plane.
> >
> >> That's the issue with consistency of label for a given FEC
> >> distributed by more then one protocol within your domain.
> >>
> >> Best,
> >> R.
> >>
> >> a packet, no matter from whichever label distribution protocol this
> >> label is learnt, the packet would definitely be forwarded to the node
> >> identified by that FEC along the shortest path.
> >> >
> >> > Could you give a concrete example to illustrate why the forwarding
> >> > result is
> >> rather poor?
> >> >
> >> > Best regards,
> >> > Xiaohu
> >> >
> >> >> -----邮件原件-----
> >> >> If your SR segments are to be engineered by set of SR headers for
> >> >> a given FEC and anywhere in the network you will suddenly choose
> >> >> LDP learned label for a given FEC the forwarding results will be
> >> >> rather poor don't
> >> you think ?
> >> >>
> >> >> r.
> >> >>
> >> >> >> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Robert
> >> >> Raszuk
> >> >> >> 发送时间: 2014年5月21日 15:25
> >> >> >> 收件人: Xuxiaohu
> >> >> >> 抄送: Hannes Gredler; Yakov Rekhter; [email-masked]; Alvaro
> >> >> >> Retana (aretana); John G. Scudder
> >> >> among routers (e.g., some routers prefer label bindings learnt
> >> >> from ISIS while others prefer label bindings learnt from LDP)?
> >> >> >
> >> >> > Best regards,
> >> >> > Xiaohu
> >> >> >
> >> >> >> Thx,
> >> >> >> R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 22 May 2014 03:32:42 +0200

Yes I did not draw another targetted session, but this is not the point.

You can't put for a given prefix multiple incoming labels in LFIB.
Only what is in the RIB from single protocol is installed in LFIB.

So you can't have both 1033 and 44 in the LFIB.

Rgs,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 22 May 2014 02:43:27 +0000

> 发送时间: 2014年5月22日 9:33
> 主题: Re: 答复: [spring] 答复: 答复: 答复: draft-gredler-spring-mpls-05.txt as
> SPRING WG document
> 

No matter whether R2 has another T-LDP session or not, the label 33 learnt from the T-LDP session with R3 should not be deemed as an incoming label. Incoming labels should always be those labels allocated by R2 itself. 

> Only what is in the RIB from single protocol is installed in LFIB.

Why can't? It's absolutely a local implementation issue. If the implementation doesn't support interoperation between different label distribution protocols, the implementation should have separate LFIB entries for each distribution protocol. In this way, there are still multiple LFIB (MPLS2MPLS) entries for a given prefix anyway. Of course, there could be only one FTN (IP2MPLS) mapping entry since one label distribution protocol is preferred to others.

Best regards,
Xiaohu

> > On R2, the label 33 learnt from T-LDP should be the outgoing label, rather
> than the ingoing label for FEC 3.3.3.3/32, one of the incoming labels for FEC
> 3.3.3.3/32 should be 1033. Another incoming label for FEC 3.3.3.3/32 is a label
> (e.g., 44) allocated by the LDP module. In other word, when receiving a packet
> with top label of either 1033 or 44, that top label would be swapped to 33.
> >
> > Best regards,
> > Xiaohu
> >
> >> -----邮件原件-----
> >> 抄送: Yakov Rekhter; [email-masked]; Hannes Gredler; John G. Scudder;
> >> Alvaro Retana (aretana)
> >> >> 抄送: Yakov Rekhter; Hannes Gredler; [email-masked]; John G.
> >> >> Scudder; Alvaro Retana (aretana)
> >> >> 主题: Re: [spring] 答复: 答复: draft-gredler-spring-mpls-05.txt as
> >> >> SPRING WG document
> >> >>
> >> >> Xu,
> >> >>
> >> >> You can't attach to a packet SR header with labels (SIDs) learned
> >> >> by ISIS and in the segment nodes use LDP learned labels for
> >> >> forwarding in your
> >> data plane.
> >> >
> >> >> a packet, no matter from whichever label distribution protocol
> >> >> this label is learnt, the packet would definitely be forwarded to
> >> >> the node identified by that FEC along the shortest path.
> >> >> >
> >> >> > Could you give a concrete example to illustrate why the
> >> >> > forwarding result is
> >> >> rather poor?
> >> >> >
> >> >> > Best regards,
> >> >> > Xiaohu
> >> >> >
> >> >> >> -----邮件原件-----
> >> >> >> 主题: Re: [spring] 答复: draft-gredler-spring-mpls-05.txt as SPRING
> >> >> >> WG document
> >> >> >>
> >> >> >> If your SR segments are to be engineered by set of SR headers
> >> >> >> for a given FEC and anywhere in the network you will suddenly
> >> >> >> choose LDP learned label for a given FEC the forwarding results
> >> >> >> will be rather poor don't
> >> >> you think ?
> >> >> >>
> >> >> >> r.
> >> >> >>
> >> >> >> On Wed, May 21, 2014 at 9:33 AM, Xuxiaohu
> <[email-masked]>
> >> >> wrote:
> >> >> >> > Robert,
> >> >> >> >
> >> >> >> >> -----邮件原件-----
> >> >> >> >> > Since there are just label distribution protocols which
> >> >> >> >> > don't affect the route selection at all, why do you care
> >> >> >> >> > about that consistency among
> >> >> >> >> routers?
> >> >> >> >>
> >> >> >> >> This is about the same FEC so same route hence route
> >> >> >> >> selection does not come to the picture.
> >> >> >> >

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 22 May 2014 05:10:26 +0200

Hi Xu,

> If the implementation doesn't support interoperation between different
> label distribution protocols, the implementation should have separate
> LFIB entries for each distribution protocol. In this way, there are still
> multiple LFIB (MPLS2MPLS) entries for a given prefix anyway.

How would you lookup mpls packets across those multiple tables ? One by one ?

> No matter whether R2 has another T-LDP session or not, the label
> 33 learnt from the T-LDP session with R3 should not be deemed as
> an incoming label. Incoming labels should always be those labels
> allocated by R2 itself.

Of course. I did not draw the targetted session to say R10 from R2
allocating 44. The point was that if at R2 targetted LDP wins over IGP
for label allocation (and we are talking about global per R2 label
space - not per interface) labels distributed by IGP for FEC 3.3.3.3
will not end up in LFIB.

The same actually for labeled-bgp and IGP global labels.

So I guess we understand each other's point now. You say to always
install all labels regardless of what protocol src FEC is in the RIB.
Specifically all labels locally allocated as well as global labels
distributed by IGP in one or many LFIBs.

I do not think this is the case today at least in few mpls
implementations. Moreover I am not sure that this is always possible
with the index based label hack to accomodate overlapping label spaces
across nodes.

Best,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 22 May 2014 04:01:06 +0000

> 发送时间: 2014年5月22日 11:10
> 主题: Re: 答复: 答复: [spring] 答复: 答复: 答复:
> draft-gredler-spring-mpls-05.txt as SPRING WG document
> 
> Hi Xu,
> 
> > LFIB entries for each distribution protocol. In this way, there are
> > still multiple LFIB (MPLS2MPLS) entries for a given prefix anyway.
> 

I didn't mean multiple tables. Instead, I mean multiple entries for a given FEC within the LFIB and each is for a separate label distribution protocol.

> > 33 learnt from the T-LDP session with R3 should not be deemed as an
> > incoming label. Incoming labels should always be those labels
> > allocated by R2 itself.
> 
> Of course. I did not draw the targetted session to say R10 from R2 allocating 44.
> The point was that if at R2 targetted LDP wins over IGP for label allocation (and
> we are talking about global per R2 label space - not per interface) labels
> distributed by IGP for FEC 3.3.3.3 will not end up in LFIB.

I'm talking about per-platform label space as well:)  As I've said before, in the interoperation mode, the outgoing label for FEC 3.3.3.3/32 would be the label advertised by LDP. However, the incoming labels for that FEC should be the labels allocated by both LDP and IGP. In the ship-in-night mode, there are two LFIB entries for FEC 3.3.3.3/32, one is from LDP (e.g., 44 (in)->33(out)) and the other is from IGP (e.g., 1033 (in)->1033(out)). As for global labels, it just mean all LSRs allocate the same label for a given FEC.

> So I guess we understand each other's point now. You say to always install all
> labels regardless of what protocol src FEC is in the RIB.
> Specifically all labels locally allocated as well as global labels distributed by IGP in
> one or many LFIBs.
> 
> I do not think this is the case today at least in few mpls implementations.

It's no surprise since as I've said it's totally a implementation issue. However, IMHO, those few MPLS implementations as you mentioned above are not ideal. At least, if T-LDP is preferred to IGP, the LSR should not advertise it as a SR anymore.

> Moreover I am not sure that this is always possible with the index based label
> hack to accomodate overlapping label spaces across nodes.

The usage of Index is just to reduce the label advertisements, and it doesn't change the nature of the MPLS architecture at all.

Best regards,
Xiaohu

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 22 May 2014 11:18:38 +0200

On Thu, May 22, 2014 at 04:01:06AM +0000, Xuxiaohu wrote:
[ ... ]
| > Moreover I am not sure that this is always possible with the index based label
| > hack to accomodate overlapping label spaces across nodes.

this is not a "hack" - its a control-plane compression scheme,
which has served us well in VPLS/L2VPN deployments - "running code", you see ?

/hannes

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 22 May 2014 16:02:33 +0200

Hey Hannes,

By "hack" I mean someting very cool, brilliant and positive here .. ;)

Cheers,
R.