Re: [mpls] Entropy in MPLS-SR-over-UDP

["Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]>]

thx

On 14/11/2017, 16:35, "Adrian Farrel" <[e-mail]> wrote:

    Yeah, OK.
    The point is we *do* use src port for entropy on the UDP tunnel, but we have to drag that value from somewhere or create it.
    
    We'll throw some text together.
    
    A
    
    > -----Original Message-----
    > From: Henderickx, Wim (Nokia - BE/Antwerp)
    > [mailto:[e-mail]]
    > Sent: 14 November 2017 07:31
    > To: [e-mail]; [e-mail]
    > Cc: [e-mail]; [e-mail]; 'Jeff Tantsura'
    > Subject: Re: Entropy in MPLS-SR-over-UDP
    > 
    > I agree but the draft claims we can do src udp port for entropy label and hence
    > people might forget this. Hence why I believe its important to define this
    > behaviour explicitly.
    > 
    > On 14/11/2017, 15:23, "Adrian Farrel" <[e-mail]> wrote:
    > 
    >     OK, we'll add text.
    > 
    >     And I think the message is "more or less" (TM) unchanged from the behavior
    > for native MPLS-SR.
    > 
    >     A
    > 
    >     > -----Original Message-----
    >     > From: Henderickx, Wim (Nokia - BE/Antwerp)
    >     > [mailto:[e-mail]]
    >     > Sent: 14 November 2017 07:15
    >     > To: [e-mail]; [e-mail]
    >     > Cc: [e-mail]; [e-mail]; Jeff Tantsura
    >     > Subject: Re: Entropy in MPLS-SR-over-UDP
    >     >
    >     > Adrian, good.
    >     > My point is we should specify the behaviour in the draft.
    >     > Your take is the ingress node of the SR-TE LSP should insert an entropy label
    > in
    >     > the stack based on RLD capabilities even though SRoUDP is used.
    >     > Only when you use SRoUDP all the way we can avoid adding the entropy
    > label.
    >     >
    >     >
    >     > On 14/11/2017, 14:56, "Adrian Farrel" <[e-mail]> wrote:
    >     >
    >     >     Hi Wim,
    >     >     A couple of observations on the question you raised at the mic...
    >     >
    >     >     An entropy value can be preserved e2e, but it is by no means necessary to
    > do
    >     > so.
    >     >
    >     >     This shows at three points in a network...
    >     >
    >     >     1. UDP tunnel ends, new UDP tunnel starts
    >     >     This the "normal" case. It is possible to conceive of storing the entropy
    > value
    >     >     and re-using it (but I don't think I would implement that). Each UDP tunnel
    > is a
    >     >     new tunnel and gets its own entropy value. Of course, if there is already an
    > EL
    >     >     in the stack, that can be extracted.
    >     >
    >     >     2. Previous hop is native MPLS-SR, next hop is UDP tunnel
    >     >     This case is just like the tunnel between two islands (first use case). The
    > UDP
    >     >     entropy value can be pulled from an EL if one is in the stack or can be
    >     >     generated locally. This is just 7510.
    >     >
    >     >     3. UDP tunnel ends, next hop is native MPLS-SR
    >     >     This case is just like the tunnel between two islands (first use case). The
    >     >     MPLS-SR entropy value might already be in an EL in the stack in which case,
    >     >     nothing to do. Or an EL might need to be made in which case it could be
    > stored
    >     >     from the incoming UDP or freshly generated. This, too, is just as 7510.
    >     >
    >     >     The crunch is that if you are worried about making an entropy value at a
    > transit
    >     >     node (for example because it would involve too much processing or exceed
    > the
    >     >     RLD) then your head end should add an EL that will survive e2e because (as
    >     >     noted) the SR stack persists just as normal for MPLS-SR.
    >     >
    >     >     Does that help?
    >     >     I think we thought this was unnecessary to expose in the text, but if you
    > think
    >     >     adding this explanation would be useful, we can do it.
    >     >
    >     >     Thanks,
    >     >     Adrian
    >     >
    >     >
    >     >
    > 
    > 
    >