Re: [mpls] Some comments on draft-kompella-mpls-entropy-lables
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [mpls] Some comments on draft-kompella-mpls-entropy-lables



Steward,

Agreed, we should define one architecture which works in all scenarios
according to me.
PWE is the priority though, but we should architect it for IP-VPN and
BGP shortcuts, etc.

Are you in favor of TTL=1? The other options might be to much impact for
existing deployments according to me.

Cheers,
Wim

-----Original Message-----
From: Stewart Bryant [mailto:stbryant at cisco.com] 
Sent: woensdag 9 juli 2008 15:06
To: HENDERICKX Wim
Cc: Kireeti Kompella; Shane Amante; Clarence Filsfils; mpls at ietf.org
Subject: Re: [mpls] Some comments on draft-kompella-mpls-entropy-lables

Wim
>
>    Entropy labels are generated by an ingress LSR, based entirely on
>    load balancing information.  However, they MUST not have values in
>    the reserved label space (0-15).  Entropy labels MUST be at the
>    bottom of the label stack, and thus the "end-of-stack" bit in the
>    label should be set.  To ensure that they are not used 
> inadvertently
> SB> MUST be set
>    for forwarding, entropy labels SHOULD have a TTL of 0.
> SB> That is a good idea, we will put it in the PW draft.
>
> WH> If we use TTL=0 and we use PHP on the egress LER with BGP 
> WH> shortcuts,
> the packet on the egress LER will be received with TTL=0. The egress 
> LER will drop this packet normally.
>
> I see 3 options for this:
> 1. Either use TTL=1 for the entropy label 2. Do something different 
> for BGP shortcuts, introduce a service label like is done for 6PE 
> e.g., but this requires changes from today's implementations and is 
> always hard.
> 3. Avoid PHP with entropy label , but this changes again current 
> deployment models which is always though.
>
> For me option 1 seems the best, unless I miss something.
>
>    Since entropy labels are generated by the ingress LSR, an egress
LSR
>    MUST be able to tell unambiguously that a given label is an entropy
>    label.  This of course depends on the underlying application.  If
any
>    ambiguity is possible, the label above the entropy label MUST be an
>    "entropy label indicator" (ELI), which says that the following
label
>    is an entropy label.  The ELI may be signaled, or may be a reserved
>    label reserved specifically for this purpose.  Fortunately, for
many
>    applications, the use of entropy labels is unambiguous, and does
not
>    need an ELI.
>
>   
That is a good point. In the case of PWE3 TTL=0 would  work because we
still have the PW label after PHP of the PE delivery label. However PWE3
should adopt the same policy as MPLS.

Stewart
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.