Subject: [mpls] Advice on draft-etf-mpls-in-udp

From: Loa Andersson <[email-masked]>
Date: Wed, 28 Jan 2015 14:01:50 +0800

Folks,

This mail to Alia (as responsible AD), Adrian (with experience from 
progressing a lot of documents) and the mpls wg co-chairs.

I became Document Shepherd rather late in the process. Ross did the
"repeated wglc" on this draft on version -07, the document was updated
after wglc as version -08. After that there has been discussions on
different parts of the document and it has been updated twice. And a
third version (-11) is in the pipe. I've not seen version -11 yet, but
among the authors there are talk about "brand new issues".

My concerns are that we are introducing to big changes without keeping
the  working group in the loop. Can you help evaluate if we need to take
the document through a new wglc, or if we are good to go?

/Loa

On 2015-01-28 09:14, Xuxiaohu wrote:
> Hi David,
>
> The text looks good to me. Thanks for your excellent work.
>
> Best regards,
> Xiaohu
>
>> -----Original Message-----
>> From: Black, David [mailto:[email-masked]]
>> Sent: Tuesday, January 27, 2015 7:51 PM
>> To: Xuxiaohu
>> Cc: Loa Andersson; [email-masked]; [email-masked];
>> Black, David
>> Subject: MPLS/UDP: Section 3.1 item 3 - rewrite
>>
>> Here's my initial attempt to clarify Section 3.1 item 3 wrt Eric Rosen's concern
>> that the source IPv6 address is the context identifier for upstream-assigned
>> context labels for multicast traffic.  I found a way to do this without talking
>> about "point" or "multipoint" characteristics of tunnel ingress/egress.
>>
>> OLD
>>     e.  An MPLS-in-UDP sender SHOULD use different IPv6 addresses for
>>         each MPLS-in-UDP tunnel that uses UDP zero-checksum mode
>>         regardless of receiver in order to strengthen the receiver's
>>         check of the IPv6 source address.  When this is not possible, it
>>         is RECOMMENDED to use each source IPv6 address for as few UDP
>>         zero-checksum mode MPLS-in-UDP tunnels as is feasible.
>> NEW
>>     e.  An MPLS-in-UDP sender SHOULD use different IPv6 addresses for
>>         each MPLS-in-UDP tunnel that uses UDP zero-checksum mode
>>         regardless of receiver in order to strengthen the receiver's
>>         check of the IPv6 source address (i.e., the same IPv6 source
>>         address SHOULD NOT be used with more than one IPv6 destination
>>         address, independent of whether that destination address is a
>>         unicast or multicast address).  When this is not possible, it
>>         is RECOMMENDED to use each source IPv6 address for as few UDP
>>         zero-checksum mode MPLS-in-UDP tunnels (i.e., with as few
>>         destination IPv6 addresses) as is feasible.
>>
>> How does that look?
>>
>> Thanks,
>> --David
>>
>>> -----Original Message-----
>>> From: Xuxiaohu [mailto:[email-masked]]
>>> Sent: Monday, January 26, 2015 11:01 AM
>>> To: Black, David
>>> Cc: Loa Andersson; [email-masked];
>>> [email-masked]
>>> Subject: Re: [mpls] ID Tracker State Update Notice:
>>> <draft-ietf-mpls-in-udp- 09.txt>
>>>
>>> Hi David,
>>>
>>> After a careful consideration, I think it should be OK for an
>>> encapsulator to use different tunnel source addresses for different
>>> UDP tunnels if these tunnels are manually configured. Sorry for that
>>> confusion. In addition, since item e has a sentence "When this is not
>>> possible,...", I believe the current text is OK for the P2P UDP tunnel
>>> case. It seems that you only need to add some text about the P2MP UDP
>> tunnel, just as what you have mentioned before.
>>>
>>> Best regards,
>>> Xiaohu
>>>
>>> ________________________________________
>>> 发件人: Black, David [[email-masked]]
>>> 发送时间: 2015年1月26日 18:40
>>> 收件人: Xuxiaohu
>>> 抄送: Loa Andersson; [email-masked];
>>> [email-masked]; Black, David
>>> 主题: RE: [mpls] ID Tracker State Update Notice:
>>> <draft-ietf-mpls-in-udp- 09.txt>
>>>
>>> First, this is a brand new concern that has not been raised previously
>>> - it's definitely different from Eric Rosen's concern, which I
>>> understand and will write clarifying text for.
>>>
>>> Second, a VPN ought to be seriously concerned with misdelivery
>>> prevention, and there's text in the security considerations section on
>>> this topic.  Item e in section 3.1 is one of the important things that
>>> this draft does towards misdelivery prevention when UDP zero checksums are
>> used with IPv6.
>>>
>>> My starting point would be - if L3VPNs have a problem with using a
>>> different
>>> IPv6 address as the source of each tunnel, then that's one more reason
>>> for L3VPNs to use UDP checksums with IPv6.
>>>
>>> I'll defer to L3VPN experts on how L3VPN address signaling currently
>>> works and the impacts of additional IPv6 addresses on that.  I'm not
>>> the right person to write L3VPN-specific text (on this or any other topic).
>>>
>>> Thanks,
>>> --David
>>>
>>>> -----Original Message-----
>>>> From: Xuxiaohu [mailto:[email-masked]]
>>>> Sent: Monday, January 26, 2015 4:42 AM
>>>> To: Black, David
>>>> Cc: Loa Andersson; [email-masked];
>>> [email-masked]
>>>> Subject: RE: [mpls] ID Tracker State Update Notice:
>>>> <draft-ietf-mpls-in-udp- 09.txt>
>>>>
>>>> Hi David,
>>>>
>>>> Just take the BGP/MPLS IP VPN with RR enabled as an example, if it
>>>> requires the tunnel encapsulator (i.e., ingress PE) to use different
>>>> source IP addresses for different tunnels, should ingress PEs notify
>>>> the address to be used as the tunnel source address to each egress
>>>> PE. Otherwise, how could egress PEs verify that the packets are received
>> from valid ingress PEs?
>>>>
>>>> Best regards,
>>>> Xiaohu
>>>>
>>>>> -----Original Message-----
>>>>> From: Black, David [mailto:[email-masked]]
>>>>> Sent: Saturday, January 24, 2015 3:15 AM
>>>>> To: Xuxiaohu
>>>>> Cc: Loa Andersson; [email-masked];
>>>> [email-masked];
>>>>> Black, David
>>>>> Subject: RE: [mpls] ID Tracker State Update Notice:
>>>>> <draft-ietf-mpls-in-udp-09.txt>
>>>>>
>>>>> Xiaohu,
>>>>>
>>>>> I'm missing something here.
>>>>>
>>>>> Eric's concern stems from the requirement that when
>>>>> upstream-assigned
>>> labels
>>>>> are in use, the source IP address identifies the label context,
>>>>> and hence
>>>> that
>>>>> source IP address has to be common across all traffic to a destination.
>>>> Eric was
>>>>> concerned that Section 3.1 item e might conflict with that requirement.
>>>>>
>>>>> The clarifying text will indicate that there is no problem here;
>>>>> when the destination IP address is a multicast address, the sender
>>>>> sends one
>>> packet,
>>>> the
>>>>> receivers each get a copy and that 1:n multicast fan-out is a
>>>>> single
>>>> "tunnel" wrt
>>>>> Section 3.1 item e.
>>>>> Every packet delivered to every receiver in that tunnel uses the
>>>>> same
>>> source
>>>> IP
>>>>> address, so there's a single label context.
>>>>>
>>>>> I do not understand the RPF and signaling concerns below.
>>>>>
>>>>> Thanks,
>>>>> --David
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Xuxiaohu [mailto:[email-masked]]
>>>>>> Sent: Thursday, January 22, 2015 8:40 PM
>>>>>> To: Black, David
>>>>>> Cc: Loa Andersson; [email-masked];
>>>>>> [email-masked]
>>>>>> Subject: RE: [mpls] ID Tracker State Update Notice:
>>>>>> <draft-ietf-mpls-in-udp- 09.txt>
>>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> I'm looking forwarding to seeing your updated text. By the way,
>>>>>> I hope you could take into account potential concerns as follows:
>>>>>>
>>>>>> 1) will it make the RPF check performed by tunnel decapsulators
>>>>>> (e.g., to determine the upstream PE of the received multicast
>>>>>> packet in the multicast VPN context) difficult when requiring a
>>>>>> tunnel encapsulator to use different tunnel source addresses for
>>>>>> different tunnels;
>>>>>> 2) does it require the encapsulator of a particular MPLS-in-UDP
>>>>>> tunnel to notify the decapsulator(s) of its possible addresses
>>>>>> to be used as the source address of that tunnel.
>>>>>>
>>>>>> Best regards,
>>>>>> Xiaohu
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Black, David [mailto:[email-masked]]
>>>>>>> Sent: Thursday, January 22, 2015 11:15 PM
>>>>>>> To: Xuxiaohu
>>>>>>> Cc: Loa Andersson; [email-masked];
>>>>>> [email-masked];
>>>>>>> Black, David
>>>>>>> Subject: RE: [mpls] ID Tracker State Update Notice:
>>>>>>> <draft-ietf-mpls-in-udp-09.txt>
>>>>>>>
>>>>>>> Xiaohu,
>>>>>>>
>>>>>>>> Since the requirement item e would introduce additional and
>>>>>>>> unexpected complexities and difficulties for the deployment,
>>>>>>>> I suggest that it'd better to remove that item.
>>>>>>>
>>>>>>> I strongly disagree.  That requirement is important to the
>>>>>>> overall design
>>>>>> goal of
>>>>>>> requiring an offsetting corruption to cause misdelivery (i.e.,
>>>>>>> a single
>>>>>> corruption
>>>>>>> should usually not result in misdelivery).
>>>>>>>
>>>>>>> There is not an actual problem here - item e is correct wrt
>>>>>>> Eric's concern,
>>>>>> but not
>>>>>>> explained clearly.    I can write the sentence or two that will be
>>>> needed to
>>>>>>> clarify
>>>>>>> how requirement e applies to P2MP UDP tunnels (i.e.,
>>>>>>> destination IP address
>>>>>> is a
>>>>>>> multicast address) *after* the upstream vs. downstream label
>>>>>>> assignment discussion is sorted out.
>>>>>>>
>>>>>>>> By the way, I feel it would be better to uniformly replace
>>>>>>>> "MPLS-in-UDP receiver/receiver node" and "MPLS-in-UDP
>>>>>>>> sender" by "tunnel decapsulator" and "tunnel encapsulator"
>>>>>>>> respectively in the whole
>>>>>>> doc.
>>>>>>>
>>>>>>> I'll defer to others on terminology, although I find the
>>>>>>> MPLS-in-UDP
>>>>>> terminology
>>>>>>> clearer because it indicates exactly which tunnel is involved.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> --David
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Xuxiaohu [mailto:[email-masked]]
>>>>>>>> Sent: Wednesday, January 21, 2015 10:22 PM
>>>>>>>> To: Black, David
>>>>>>>> Cc: Loa Andersson; [email-masked];
>>>>>>>> [email-masked]
>>>>>>>> Subject: RE: [mpls] ID Tracker State Update Notice:
>>>>>>>> <draft-ietf-mpls-in-udp- 09.txt>
>>>>>>>>
>>>>>>>> Hi David and all,
>>>>>>>>
>>>>>>>> Since the requirement item e would introduce additional and
>>>>>>>> unexpected complexities and difficulties for the deployment,
>>>>>>>> I suggest that it'd better to remove that item.
>>>>>>>>
>>>>>>>> By the way, I feel it would be better to uniformly replace
>>>>>>>> "MPLS-in-UDP receiver/receiver node" and "MPLS-in-UDP
>>>>>>>> sender" by "tunnel decapsulator" and "tunnel encapsulator"
>>>>>>>> respectively in the whole
>>>>>>> doc.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Xiaohu
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Black, David [mailto:[email-masked]]
>>>>>>>>> Sent: Thursday, January 22, 2015 3:17 AM
>>>>>>>>> To: Eric C Rosen; Alia Atlas; Xuxiaohu
>>>>>>>>> Cc: Loa Andersson; <[email-masked]>;
>>>>>>>>> [email-masked];
>>>>>>>>> [email-masked];
>>>>>>>>> IJsbrand Wijnands; Black, David
>>>>>>>>> Subject: RE: [mpls] ID Tracker State Update Notice:
>>>>>>>>> <draft-ietf-mpls-in-udp-09.txt>
>>>>>>>>>
>>>>>>>>> Eric,
>>>>>>>>>
>>>>>>>>> On the further issue ...
>>>>>>>>>
>>>>>>>>>> There is one further issue for you to consider.
>>>>>>>>>>
>>>>>>>>>> When an MPLS packet with an upstream-assigned label is
>>>>>>>>>> received through a particular tunnel, the "context" in
>>>>>>>>>> which the label is interpreted is determined by the IP
>>>>>>>>>> address of the
>>>> root of
>>>>> the tunnel.
>>>>>>>>>> (See section 7 of RFC5331.)  For a UDP tunnel, this
>>>>>>>>>> would mean that the label space is identified by the Source IP
>> address.
>>>>>>>>>> So if a particular router is using MPLS-in-UDP to send
>>>>>>>>>> MPLS packets with upstream-assigned labels, it's really
>>>>>>>>>> important for it to use the same IP
>>>>>>>> source
>>>>>>>>> address in all
>>>>>>>>>> MPLS-in-UDP packets that have the same destination address.
>> I
>>>> can't
>>>>>>>>>> quite tell whether this is compatible with item e. in
>>>>>>>>>> section
>>>>>>>>>> 3.1 of the draft.
>>>>>>>>>
>>>>>>>>> That is compatible with item e., but the draft doesn't say
>>>>>>>>> much about P2MP
>>>>>>>> UDP
>>>>>>>>> tunnels.  In particular, I would view that source IP
>>>>>>>>> address as the source
>>>>>>>> IP
>>>>>>>>> address for a (one) P2MP tunnel, and it's probably a good
>>>>>>>>> idea to add some
>>>>>>>> text
>>>>>>>>> on P2MP UDP tunnels to make this clear.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> --David
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Eric C Rosen [mailto:[email-masked]]
>>>>>>>>>> Sent: Wednesday, January 21, 2015 11:26 AM
>>>>>>>>>> To: Alia Atlas; Xuxiaohu
>>>>>>>>>> Cc: [email-masked]; Black, David; Loa Andersson;
>>>>>>>>>> <mpls- [email-masked]>; [email-masked];
>>>>>>>>>> draft-ietf-mpls-in- [email-masked]; IJsbrand
>>>>>>>>>> Wijnands
>>>>>>>>>> Subject: Re: [mpls] ID Tracker State Update Notice:
>>>>>>>>>> <draft-ietf-mpls-in-udp- 09.txt>
>>>>>>>>>>
>>>>>>>>>> Folks,
>>>>>>>>>>
>>>>>>>>>> I'll be happy to throw in my much belated two cents.
>>>>>>>>>>
>>>>>>>>>> If I understand correctly, the issue at hand is how one
>>>>>>>>>> determines, when receiving an MPLS-in-UDP packet,
>>>>>>>>>> whether the top MPLS label is upstream-assigned or
>> downstream-assigned.
>>>>>>>>>>
>>>>>>>>>> Draft-ietf-mpls-in-udp-10 has the following text:
>>>>>>>>>>
>>>>>>>>>>      As for whether the top label in the MPLS label stack is
>>>>>>>>>>      downstream-assigned or upstream-assigned, it SHOULD
>>>>>>>>>> be
>>>>>>> determined
>>>>>>>>>>      based on the tunnel destination IP address.  That is
>>>>>>>>>> to say, if
>>>>>> the
>>>>>>>>>>      destination IP address is a multicast address, the
>>>>>>>>>> top label
>>>>>> SHOULD
>>>>>>>>>>      be upstream-assigned, otherwise if the destination
>>>>>>>>>> IP
>>> address
>>>> is a
>>>>>>>>>>      unicast address, it SHOULD be downstream-assigned.
>>>>>>>>>>
>>>>>>>>>> I believe this text is incorrect, as it is inconsistent
>>>>>>>>>> with RFCs
>>>>>>>>>> 5332 and 5331, which are the RFCs that introduce the
>>>>>>>>>> notion of "upstream-assigned labels".
>>>>>>>>>>
>>>>>>>>>> Of particular relevance is Section 3 of RFC 5332, which
>>>>>>>>>> discusses how one determines, when an MPLS packet is
>>>>>>>>>> being sent through a tunnel, whether the top label of
>>>>>>>>>> the encapsulated packet is upstream or
>>>>>>>> downstream.
>>>>>>>>>>
>>>>>>>>>> To make a long story short, basically what that section
>>>>>>>>>> says is that the tunnel must be known a priori to have
>>>>>>>>>> one of the following three
>>>>>>>>> properties:
>>>>>>>>>>
>>>>>>>>>> 1. The top label of all encapsulated packets is
>>>>>>>>>> downstream-
>>>> assigned.
>>>>>>>>>>
>>>>>>>>>> 2. The top label of all encapsulated packets is
>>>>>>>>>> upstream-
>>> assigned.
>>>>>>>>>>
>>>>>>>>>> 3. The top label of some encapsulated packets is
>>>>>>>>>> downstream-assigned, but the top label of some
>>>>>>>>>> encapsulated packets is
>>>>>>> upstream-assigned.
>>>>>>>>>>
>>>>>>>>>> How it is known which property the tunnel has is out of
>>>>>>>>>> scope (i.e., it depends on the higher layer).
>>>>>>>>>>
>>>>>>>>>> Only tunnels with the third property need to contain a
>>>>>>>>>> codepoint that specifies whether the label is
>>>>>>>>>> upstream-assigned or
>>>>>>> downstream-assigned.
>>>>>>>>>>
>>>>>>>>>> So what does all this mean for the mpls-in-udp encapsulation?
>>>>>>>>>> I would suggest that you say the following:
>>>>>>>>>>
>>>>>>>>>> - Have IANA assign a single UDP port number for MPLS-in-UDP.
>>>>>>>>>>
>>>>>>>>>> - In the absence of any other knowledge, a UDP packet
>>>>>>>>>> with the MPLS-in-UDP port number in destination port
>>>>>>>>>> field is assumed to be carrying an MPLS packet whose top
>>>>>>>>>> label is
>>>>> downstream-assigned.
>>>>>>>>>>
>>>>>>>>>> - Higher layers may negotiate the use of particular UDP
>>>>>>>>>> tunnels to carry MPLS packets whose top labels are
>>>>>>>>>> upstream-assigned.  The procedures for such negotiation
>>>>>>>>>> are out of scope of the current document.  By a
>>>>>>>>>> "particluar UDP tunnel", I mean a UDP tunnel with a
>>>>>>>>>> particular <source IP address, destination IP address,
>>>>>>>>>> destination
>>>>>>>>>> port> triple.  The destination port may be the standard
>>>>>>>>>> (IANA-assigned) port number for MPLS-in-UDP, but it may
>>>>>>>>>> also be any other port number that is negotiated by the higher
>> layer.
>>>>>>>>>>
>>>>>>>>>> - For a particular UDP tunnel (i.e., a particular
>>>>>>>>>> <source address, destination address, destination port>
>>>>>>>>>> triple), all the encapsulated MPLS packets must have the
>>>>>>>>>> same type of label at the top
>>>>>> of
>>>>>>> the stack.
>>>>>>>>>>
>>>>>>>>>> - Remove any suggestion that the type of the label can
>>>>>>>>>> be inferred from the type of the IP destination address.
>>>>>>>>>>
>>>>>>>>>> I think this will make the draft compatible with RFCs
>>>>>>>>>> 5332 and 5331, and it does not require IANA to allocate
>>>>>>>>>> a second port
>>>> number.
>>>>>>>>>>
>>>>>>>>>> Note, by the way, that if we are going to allow the
>>>>>>>>>> higher layers to negotiate the destination port number,
>>>>>>>>>> we should probably caution implementers not to hard code
>>>>>>>>>> (or hard wire) a particular port
>>>>>>> number.
>>>>>>>>>>
>>>>>>>>>> There is one further issue for you to consider.
>>>>>>>>>>
>>>>>>>>>> When an MPLS packet with an upstream-assigned label is
>>>>>>>>>> received through a particular tunnel, the "context" in
>>>>>>>>>> which the label is interpreted is determined by the IP
>>>>>>>>>> address of the
>>>> root of
>>>>> the tunnel.
>>>>>>>>>> (See section 7 of RFC5331.)  For a UDP tunnel, this
>>>>>>>>>> would mean that the label space is identified by the Source IP
>> address.
>>>>>>>>>> So if a particular router is using MPLS-in-UDP to send
>>>>>>>>>> MPLS packets with upstream-assigned labels, it's really
>>>>>>>>>> important for it to use the same IP
>>>>>>>> source
>>>>>>>>> address in all
>>>>>>>>>> MPLS-in-UDP packets that have the same destination address.
>> I
>>>> can't
>>>>>>>>>> quite tell whether this is compatible with item e. in
>>>>>>>>>> section
>>>>>>>>>> 3.1 of the draft.
>>>>>>>>>>
>>>>>>>>>> Eric
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Alia Atlas <[email-masked]>
Date: Wed, 28 Jan 2015 10:31:34 -0500

Hi Loa,

> the document through a new wglc, or if we are good to go?

I am keeping a close eye on this question. So far, I think that we are good
to
go once the discusses and upstream labels questions are addressed.

On the latter,  I believe it is resolving to behavior as specified in the
draft
from WGLC - but with the clarification that in the future some signalling
might
indicate whether the labels are not upstream assigned even if the IP
destination
address is multicast.

The two discusses are not, IMHO, changing any technical details but rather
clarifying details.  For instance, there isn't a listener at the UDP source
port
on the ingress of the UDP tunnel.  For another instance, clarifying the DTLS
behavior in terms of number of expected sessions.

I do hope to see an updated draft that addresses the discusses very soon
and would encourage prodding by the shepherd ;-)

Thanks,
Alia

/Loa