Subject: Re: I-D ACTION:draft-chakravorty-6lsa-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Jul 2004 14:08:24 +0200

Hi,

This is an interesting draft but it has some serious problems IMHO.

They start in section 6.2 Flow:

>    There may be multiple active flows in the 6LSA at any given time.  Further 
> applicable statements are quoted here from [3] RFC 2460 for clarity. 

Unfortunately the quotations are all from Appendix A of that RFC, which
is non-normative and is obsoleted by RFC 3697. Section 2 of the draft says:

> The specification of IPv6 label is in 
>    conformance with [2] RFC 3697, 

but in fact the draft appears to violate even the very broad criteria
of RFC 3697. The quotations from 2460 are in fact misleading, and should
be replaced by explicit reference to 3697.

The key sentence in 3697 that this draft appears to break repeatedly is:

(1)   The Flow Label value set by the source MUST be delivered unchanged to
       the destination node(s).

And another very important sentence (the next one in fact) which the draft
also appears to break is:

(2)   IPv6 nodes MUST NOT assume any mathematical or other properties of
       the Flow Label values assigned by source nodes.

Now to the specific problems with the draft:

> 6.5 
>      Labeled Packet 
...
>  
> All packets in a flow in 6LSA have a non-zero label value, while all packets in a 
> pseudoflow may have zero label value.  If an incoming packet into a 6LSA node has a 
> zero label value and it is not a lead packet (see Section 6.7), it is assigned a non-
> zero label value before forwarding it. 

Apparently violates (1)

> 6.6 
>      IPv6 Label Switching Router (6LSR) 
>  
> A router operating in the 6LSA is an IPv6 label switching router, called 6LSR, which 
> performs as a minimum the two 6LSA functions of: 1) replacing (swapping) an incoming 
> label in a packet with an outgoing label, ...

Apparently violates (1)

> ...and 2) forwarding the packet based on the 
> appropriate forwarding treatment.  If the packet is not to be assigned to a FEC, as
> in the case when the packet exits a 6LSA network and if it is a subsequent packet, 
> the non-zero label is removed and in its place the original non-6LSA label, a zero 
> value label, is inserted as needed.   

This seems to say that in this case the original (zero) label is restored -
which does *not* violate (1).

> 6.11 
>       IPv6 Label Switched Path (6LSP) 
...
>  
>   ò  R1, the ingress 6LSR, acquires a label and swaps it with the current label in 
>       packet P unless the packet is a lead packet; 

Apparently violates (1)

...

>   ò  Rn, the egress 6LSR, removes the incoming label and swaps it with the original 
>       label (that the ingress 6LSR received) and forwards the packet out based on the 
>       next-hop address unless there is penultimate 6LSR label swapping, in which 
>       case, Rn may forward the packet based on the FEC but without binding the 
>       outgoing label to the FEC.   

It seems that in this case, the original label is restored, so (1) is *not*
violated, but how does the egress 6LSR know the correct label to restore? The
draft explicitly doesn't define a label distribution protocol or any other
mechanism for this. Note however that to meet the RFC 3697 requirement,
the original label MUST be restored for every packet in every case.

> 7.1.3  Reuse Label Model 
>  
> The 6LSA allows a node to reuse existing label available in the node or obtained from 
> labels in the incoming packets and where the flows can be associated with unique 
> label bindings.   

The clear assumption of RFC 3697 is that the same label will be used end to end,
with uniqueness based on the {src,dst,label} tuple. This is the nearest the draft
gets to conformity with 3697.

>  
> This label model is not recommended for large 6LSA domains; in large domains 
> undesirable duplication of labels can occur.  This model requires a single-bit field, 
> the MSB field, in the label to represent the identity of the packet as the lead 
> packet or non-lead packet.  

This appears to violate (2). IPv6 flow labels are not encoded.

 > 7.7.1.2  Algorithm for Non-Merging Flows
...
> c)  Egress 6LSR: when a packet arrives on an interface, match the incoming label and 
>     interface with those in the switching table. 
...
>   ii) If there is a match for only the incoming label and not the interface, then 
>       this is a lead packet; look up the next-hop route and make switching table 
>       entry for this packet including the label, the PID value of 0 (zero) and route 
>       for the outgoing packet, and forward the packet out; there is no swapping of 
>       labels if the incoming label is 0 (zero) otherwise swap the incoming label 
>       with 0 (zero) label for the peering best-effort network. 

This appears to violate (1).

>   iii)If there is a match for both the label and interface in the same entry, this 
>       is an NTL or a subsequent packet in this flow; switch the incoming label with 
>       0 (zero) label and forward the packet out for the peering best-effort network 
>       based on the next-hop route from the switching table. 

This appears to violate (1).

 > 7.7.1.3  Algorithm for Merging Flows
...
> c)  In the egress 6LSR, when a packet arrives on an interface, match the incoming 
>     label and interface with those in the switching table. 
>  
...
> ii) If there is a match for only the incoming label and not the interface, and the 
>     PID value is 0 (zero) in the switching table, then this is a lead packet; look 
>     up the next-hop route and make switching table entry for this packet including 
>     the label, the PID value of 0 (zero), and route for the outgoing packet, forward 
>     the packet out; swap the incoming label with the 0 (zero) outgoing label if the 
>     incoming label is non-zero. 

This appears to violate (1).

> iii)If there is a match for both the label and the interface in the same entry, then 
>     this is an NTL or a subsequent packet in this flow or another flow (if the 
>     upstream 6LSR is merging flows).  Find matches for the source and destination 
>     addresses ¡ 
>  
> o   If there is a match of the addresses, this is a next-to-lead or subsequent 
>     packet; increment the PID to 1 (one) and forward the packet out after swapping 
>     incoming label with a 0 (zero) label. 

This appears to violate (1).

> 8. 
>     Security Considerations 

I think the discussion of tunnels in RFC 3697, section 5.2, is sufficient.

     Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------