Subject: Re: [mpls] Advice on draft-ietf-mpls-in-udp

From: "Black, David" <[email-masked]>
Date: Wed, 28 Jan 2015 17:34:59 +0000

Hi Loa,

First of all, thanks for everything you’ve been doing for this draft.  In some sense, we threw you in at the deep end of the pool when you became shepherd late in the process, although that’s been the experience of most of us who’ve been working on this draft for the past 6 months; there’s a lot more going on here than any of us initially expected.

That said, Alia’s take on this draft’s state and the thread below matches mine - there’s a bunch of small clarifications in progress but nothing big.  In the thread below, Xiaohu and I wind up agreeing that there is not an L3VPN-related problem that this draft needs to address.  The resulting clarification in the additional text is fairly simple (and was always intended by the current text) - an MPLS-in-UDP tunnel is identified by its source and destination IP addresses (IPv6 in the added text below courtesy of where it occurs in the draft).  The UDP ports do not provide any additional identification because the destination port is a constant, and the source port is used solely to inject entropy (e.g., for multipathing).

Thanks,
--David

From: mpls [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Wednesday, January 28, 2015 10:32 AM
To: Loa Andersson
Cc: [email-masked]
Subject: Re: [mpls] Advice on draft-etf-mpls-in-udp

Hi Loa,

On Wed, Jan 28, 2015 at 1:01 AM, Loa Andersson <[email-masked]<mailto:[email-masked]>> wrote:
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?

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

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]<mailto:[email-masked]>]
Sent: Tuesday, January 27, 2015 7:51 PM
To: Xuxiaohu
Cc: Loa Andersson; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[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]<mailto:[email-masked]>]
Sent: Monday, January 26, 2015 11:01 AM
To: Black, David
Cc: Loa Andersson; [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[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]<mailto:[email-masked]>]
发送时间: 2015年1月26日 18:40
收件人: Xuxiaohu
抄送: Loa Andersson; [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[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]<mailto:[email-masked]>]
Sent: Monday, January 26, 2015 4:42 AM
To: Black, David
Cc: Loa Andersson; [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[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]<mailto:[email-masked]>]
Sent: Saturday, January 24, 2015 3:15 AM
To: Xuxiaohu
Cc: Loa Andersson; [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[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]<mailto:[email-masked]>]
Sent: Thursday, January 22, 2015 8:40 PM
To: Black, David
Cc: Loa Andersson; [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[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]<mailto:[email-masked]>]
Sent: Thursday, January 22, 2015 11:15 PM
To: Xuxiaohu
Cc: Loa Andersson; [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[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]<mailto:[email-masked]>]
Sent: Wednesday, January 21, 2015 10:22 PM
To: Black, David
Cc: Loa Andersson; [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[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]<mailto:[email-masked]>]
Sent: Thursday, January 22, 2015 3:17 AM
To: Eric C Rosen; Alia Atlas; Xuxiaohu
Cc: Loa Andersson; <[email-masked]<mailto:[email-masked]>>;
[email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[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]<mailto:[email-masked]>]
Sent: Wednesday, January 21, 2015 11:26 AM
To: Alia Atlas; Xuxiaohu
Cc: [email-masked]<mailto:[email-masked]>; Black, David; Loa Andersson;
<mpls- [email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
draft-ietf-mpls-in- [email-masked]<mailto:[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]<mailto:[email-masked]>
Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
Huawei Technologies (consultant)     phone: +46 739 81 21 64<tel:%2B46%20739%2081%2021%2064>

---

From: Loa Andersson <[email-masked]>
Date: Thu, 29 Jan 2015 12:35:57 +0800

All,

Tnx - I wanted to bring this (too many changes concern) up now rather
than just prior to the telechat. I'm on the same page as Alia and David,
good to go, once discusses are resolved.

/Loa

On 2015-01-29 01:34, Black, David wrote:
> Hi Loa,
>
> First of all, thanks for everything you’ve been doing for this draft.
> In some sense, we threw you in at the deep end of the pool when you
> became shepherd late in the process, although that’s been the experience
> of most of us who’ve been working on this draft for the past 6 months;
> there’s a lot more going on here than any of us initially expected.
>
> That said, Alia’s take on this draft’s state and the thread below
> matches mine - there’s a bunch of small clarifications in progress but
> nothing big.  In the thread below, Xiaohu and I wind up agreeing that
> there is not an L3VPN-related problem that this draft needs to address.
> The resulting clarification in the additional text is fairly simple (and
> was always intended by the current text) - an MPLS-in-UDP tunnel is
> identified by its source and destination IP addresses (IPv6 in the added
> text below courtesy of where it occurs in the draft).  The UDP ports do
> not provide any additional identification because the destination port
> is a constant, and the source port is used solely to inject entropy
> (e.g., for multipathing).
>
> Thanks,
> --David
>
> *From:*mpls [mailto:[email-masked]] *On Behalf Of *Alia Atlas
> *Sent:* Wednesday, January 28, 2015 10:32 AM
> *To:* Loa Andersson
> *Cc:* [email-masked]
> *Subject:* Re: [mpls] Advice on draft-etf-mpls-in-udp
>
> Hi Loa,
>
> This mail to Alia (as responsible AD), Adrian (with experience from
> progressing a lot of documents) and the mpls wg co-chairs.
>
>     Cc: Loa Andersson; [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>;
>     Black, David
>     From: Xuxiaohu [mailto:[email-masked] <mailto:[email-masked]>]
>     Cc: Loa Andersson; [email-masked]
>     <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>
>     发件人: Black, David [[email-masked] <mailto:[email-masked]>]
>     发送时间: 2015年1月26日 18:40
>     收件人: Xuxiaohu
>     抄送: Loa Andersson; [email-masked]
>     <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>; Black, David
>     From: Xuxiaohu [mailto:[email-masked] <mailto:[email-masked]>]
>     Cc: Loa Andersson; [email-masked]
>     <mailto:[email-masked]>;
>
>     [email-masked] <mailto:[email-masked]>
>
>         Cc: Loa Andersson; [email-masked]
>         <mailto:[email-masked]>;
>
>         [email-masked] <mailto:[email-masked]>;
>
>         Black, David
>     From: Xuxiaohu [mailto:[email-masked] <mailto:[email-masked]>]
>     Cc: Loa Andersson; [email-masked]
>     <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>
>     Cc: Loa Andersson; [email-masked]
>     <mailto:[email-masked]>;
>
>     [email-masked] <mailto:[email-masked]>;
>
>     Black, David
>         Cc: Loa Andersson; [email-masked]
>         <mailto:[email-masked]>;
>         [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>;
>         [email-masked]
>         <mailto:[email-masked]>;
>                     Cc: [email-masked] <mailto:[email-masked]>;
>                     Black, David; Loa Andersson;
>                     <mpls- [email-masked]
>                     <mailto:[email-masked]>>;
>     Senior MPLS Expert [email-masked] <mailto:[email-masked]>

-- 

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