Subject: Re: TTL in ATM over MPLS

From: John Fischer <[email-masked]>
Date: Thu, 27 Feb 2003 15:15:24 -0500

Yes you're correct, but I think that it would be quite difficult to get
this packet with a correct label and TTL=2 delivered to the PE in
the first place if that label was exposed for several hops.  The
inner MPLS label is only known by the PE in L2 VPN, L3 VPN
and VPLS.

I agree that setting TTL to 255 and checking for 254/255 at the
PE is more secure.  As David Allan indicates though, this depends
on the pipe or uniform behaviour of the penultimate LSR and
requires extra checks at the PE.  By using TTL 2, basic TTL
handling can be used at the PE.
John

Renwei Li wrote:

> You are assuming the network is well-configured. But I am considering
> what will happen if the network is not well-configured.
>
> The bottom line is: when an LSR receives a packet with TTL 255, it is
> sure that the packet was sent one hop away from. But if it receives a
> packet with TTL 2, it is not sure how far the packet was sent away from.
> Maybe 1 hop, 2 hops, 3 hops, .... We really can't judge from that.
>
> In view of the above, I believe you can easily give a mis-configured
> network so that the egress PE receives a packet with TTL 2, but the
> packet is not really a valid one sent from the ingress PE.
>
> Renwei
>
> -----Original Message-----
> From: John Fischer [mailto:[email-masked]]
> Sent: Thursday, February 27, 2003 6:06 AM
> To: [email-masked]
> Cc: Renwei Li; [email-masked]
> Subject: Re: [PWE3] TTL in ATM over MPLS
>
> In addition, the tunneling context (could be an outer MPLS label)
> may be popped at the penultimate node if PHP was requested by
> the PE.  The inner label should only be exposed for 1 hop.  Setting
> the TTL to 2 prevents the the packet from travelling any further than
> it should need to go.
> John
>
> [email-masked] wrote:
>
> > Renwei Li wrote 26 February 2003 23:14
> > > To: [email-masked]
> > > Subject: [PWE3] TTL in ATM over MPLS
> > >
> > >
> > > In the draft pwe3-atm-encap-01.txt, it says:
> > >
> > >    The ingress LSR, PE1, SHOULD set the TTL field of the VC label to
> a
> > > value of 2.
> > >
> > > IMHO, it is better to set to 255. The egress PE2 should discard the
> > > packets if its TTL is other than 255. TTL 255 will prevent
> > > from the use
> > > of VC label for transporting purpose.
> > NH=> Good point....but it has a downside:  If there is a defect that
> causes
> > misdelivery (ie swap/mismerge fault) then the traffic could be
> delivered to
> > wrong location.  Setting the TTL to 2 helps stop this possibility.
> >
> > regards, Neil
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Eric Rosen <[email-masked]>
Date: Fri, 28 Feb 2003 10:25:48 -0500

One thing to remember is that the TTL  is part of the PSN layer, not part of
the  PWE3 layer.   Adding a  rule like  "throw away  a packet  if  its label
indicates that it is a PWE3 packet  but its TTL is not 255", would be making
a change to the basic MPLS  forwarding logic.  And as Dave Allan has pointed
out  several times,  the MPLS  forwarding logic  is not  even  guaranteed to
preserve edge-to-edge the TTL of the bottom label stack entry.

Frankly, I  don't like the  rule of setting  the TTL of  the PW label  to 2.
This rule embeds two assumptions: 

- The PW label is always at the bottom of the label stack. 

- There will never been any "tunnel switching", in which a single PW travels
  part way through one LSP tunnel,  exits the tunnel, and then gets switched
  into another LSP tunnel.  

I'm  not sure  that either  of these  assumptions can  be inferred  from the
architecture.