Re: [Idr] draft on virtual aggregation

[Paul Francis <[e-mail]>]

> -----Original Message-----
> From: Daniel Ginsburg [mailto:[e-mail]]
> Sent: Tuesday, July 08, 2008 8:13 PM
> To: Paul Francis
> Cc: [e-mail]
> Subject: Re: [Idr] draft on virtual aggregation
> 
> Paul Francis wrote:
> 
> > Ok, I'll dig back into RFC5036.  I was assuming that, since the
> external
> > router is the target of the tunnel, but since the border router
> detunnels,
> > then this meant PHP.
> >
> 
> Since the border router is the first one which assigns a label to a
> prefix, I think it qualifies as ultimate hop. Just in case: I assume
> that the draft doesn't require speaking LDP to an external peer, right?

Right.

> 
> >> terminology). I.e. it means that a border VA router must not
> advertise
> >> implicit (or explicit) null label for FECs corresponding to external
> >> next-hops.
> >
> > I'm afraid that I'm not up enough on MPLS terminology to even know
> what the
> > above means.  My bad.  I'll figure it out.
> 
> It simply means that a border router must assign a separate non null
> label for each external next-hop to be able avoid doing L3 lookup for
> any of egressing packets and switch the packets solely on that label. I
> think this is what you intended in your draft.

Exactly. 

> 
> I think that there might be some implementation difficulties when
> there're multiple external next-hops on a multiple access link, but
> I'll
> leave this to others, who are far more knowledgeable than me about
> current implementations, to comment.
> 
> >
> >> Also section 3.2.3 implies that external next-hops must be
> >> carried inside AS' IGP, and IMHO the draft should explicitly say so.
> >
> > Good point---will add this in the next version.  BTW, of course
> another
> > approach would be to use stacked labels, with the outer label
> targeting the
> > border router, and the inner label identifying the external peer.
> I'd love
> > to hear what people think of this as an alternative (or additional)
> approach.
> >
> 
> Well, you might need to extend LDP to be able to do that. Probably,
> procedures outlined in Kireeti Kompella's presentation
> (http://www.isocore.com/mpls2007/cd/Presentations/132%20Kireeti%20Kompe
> lla.pdf)
> might help. Though I'm not sure about standardization status of this
> approach.

Actually I had more in mind to do it in the style of MPLS-VPNs.  That is,
carry the inner label in a new BGP multi-protocol extension created for this
purpose.  

> 
> >> Another problem is mixing legacy hop-by-hop forwarding and VA.
> Consider
> >> the following topology.
> >>
> >>      10
> >> A--------B
> >> |        |
> >> |100     | 10
> >> |        |
> >> C--------D------E
> >>     10       10
> >>
> >> A, B, D are VA routers. A is APR. B and E are legacy routers capable
> of
> >> only hop-by-hop forwarding, i.e. not doing MPLS. Link metrics are
> >> shown.
> >>
> >> Packets ingress the topology at A. They get forwarded to B as plain
> IP
> >> since B is not an LSR. B forwards plain IP packets to D. D is a VA
> >> router and has suppressed the specific routes, thus it sends the
> >> packets
> >> back to A.
> >
> > Yes.  This is why the draft states (clearly, I hope!) that legacy
> routers
> > must at least do MPLS.  If this is a problem (i.e., there are legacy
> routers
> > that don't do MPLS), then I believe that there is a way around this
> problem,
> > but it is a bit complex and I'd like to avoid it.
> >
> 
> As I read the draft you still reserve a possibility of throwing
> hop-by-hop forwarding routers into the mix (section 2.1 and 3.2.1).
> IMHO, it is the best to avoid complexities of such configuration and
> strictly require all the routers to do MPLS.
> 

Ah, I see the confusion.  Yes, it is certainly my intent that legacy routers
must absolutely do MPLS and maintain the full set of tunnels.

That text is referring to the (hypothetical) case where some legacy router
has a tunnel to the next hop, but nevertheless chooses to use its
IGP-resolved interface rather than its tunnel interface.  This strikes me as
weird behavior, but I didn't want to assume that there is no router anywhere
that might do this (or might accidently be configured to do this), so I
mention it in the document.  If nobody knows of any router that does this,
I'm more than happy to take it out of the text to help avoid confusion..

PF


> 
> > PF
> >
> >> --
> >> dg
> 
> --
> dg
_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr