The MPLS WG Archive

[S Mahadevan-A19066 <mahadevan.s@motorola.com>]

Please find my responses inline...
(indicated by <RESPONSE> tag)

-----Original Message-----
From: Leonardo Balliache [mailto:lbb@opalsoft.net]
Sent: Monday, October 13, 2003 7:57 PM
To: MPLS-WG
Subject: Re: I-D ACTION:draft-ietf-mpls-in-ip-or-gre-03.txt


At 01:55 p.m. 10/09/03 -0400, you wrote:

>Title           : Encapsulating MPLS in IP or Generic Routing 
>Encapsulation (GRE)
>Author(s)     : Y. Rekhter, E. Rosen
>Filename        : draft-ietf-mpls-in-ip-or-gre-03.txt
>Pages           : 9
>Date            : 2003-9-10
>

    With these encapsulations, it is possible for two LSRs that are
    adjacent on an LSP to be separated by an IP network, even if that IP
    network does not provide MPLS.

           IP Header
                 This field contains an IPv4 or an IPv6 datagram header
                 as defined in [RFC791] and [RFC2460] respectively. The
                 source and destination addresses are set to addresses
                 of the encapsulating and decapsulating LSRs respectively.

Ok.

I draw a little scheme:

                          head                  tail
    A             M         X      IP tunnel     Y          N                 B
---o------o------o---------o....................o----------o--------o--------o
   LSR    LSR    LSR   encapsulator        decapsulator    LSR      LSR 
  LSR

My doubts:

Q1: Your specification calls for:

Both, X & Y must be MPLS capable?     or,

X, but not necessarely Y, must be MPLS capable?     or,

Y, but not necessarely X, must be MPLS capable?     or,

Neither of them have to be necessarely MPLS capable?

<RESPONSE>Both X and Y must be MPLS capable. Here X is the "tunnel head"
because it encapsulates the received MPLS packet into IP and Y is the
"tunnel tail" because it decapsulates the packet. X needs to understand the
incoming packet's label and select a destination IP address (this mechanism
is not specified in the draft). Y decapsulates the IP header and forwards the
packet according to its top most label. In case I am wrong, I request the authors
to clarify this point.</RESPONSE>

Which router pop the last top label? M or X?
<RESPONSE>NONE of them need to pop the top label. Tunnel Head should
NOT be confused with an MPLS egress node. X just encapsulates the MPLS packet
it receives into IP</RESPONSE>

Which router push again a label? Y or N?
<RESPONSE>NONE of them need to push a label. (Well, they may do so, but it is not
necessary). The decapsulated IP packet will already contain a top label which can
be used to take a normal MPLS forwarding decision. Again Tunnel Tail should NOT be
confused with an MPLS ingress node.</RESPONSE>

Q2: This paragraph:

    In some cases, the tunnel head receives, for encapsulation, an IP
    packet, which it first encapsulates in MPLS and then encapsulates in
    MPLS-in-IP or MPLS-in-GRE.  If the source of the IP packet is
    reachable from the tunnel head, and if the result of encapsulating
    the packet in MPLS would be a packet whose size exceeds the Tunnel
    MTU, then the value which the tunnel head SHOULD use for the purposes
    of fragmentation and PMTU discovery outside the tunnel is the Tunnel
    MTU value minus the size of the MPLS sencapsulation.

Could be explained a little better?

<RESPONSE>This is a case in which an ingress LSR also happens to be
the tunnel head. In that case the LSR first encapsulates the incoming
packet using its FTN. Then it encapsulates the packet into another
IP header.
In that case the tunnel head should take the MPLS overhead also into
account while advertising the tunnel MTU.

i.e IF
MPLS overhead = MPLS_OH
Actual IP Tunnel MTU = IP_MTU
THEN value of PMTU advertised outside the tunnel = IP_MTU - MPLS_OH

Thats because the IP source will then send packets small enough
to fit into the IP tunnel even after being encapsulated using MPLS.
</RESPONSE>

Best regards,

Leonardo Balliache

Pd: Perhaps, the scheme is not too bad to include it in the draft.

Practical QoS
http://opalsoft.net/qos