internet-drafts | 31 Jan 11:28 2015
Picon

New Version Notification - draft-ietf-mpls-in-udp-11.txt


A new version (-11) has been submitted for draft-ietf-mpls-in-udp:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-in-udp-11.txt

Sub state has been changed to AD Followup from Revised ID Needed

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-in-udp-11

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.

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

internet-drafts | 31 Jan 11:28 2015
Picon

I-D Action: draft-ietf-mpls-in-udp-11.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

        Title           : Encapsulating MPLS in UDP
        Authors         : Xiaohu Xu
                          Nischal Sheth
                          Lucy Yong
                          Ross Callon
                          David Black
	Filename        : draft-ietf-mpls-in-udp-11.txt
	Pages           : 18
	Date            : 2015-01-31

Abstract:
   This document specifies an IP-based encapsulation for MPLS, called
   MPLS-in-UDP (User Datagram Protocol) for situations where UDP
   encapsulation is preferred to direct use of MPLS, e.g., to enable
   UDP-based ECMP (Equal Cost Multi-Pathing) or link aggregation.  The
   MPLS-in-UDP encapsulation technology must only be deployed within a
   single network (with a single network operator) or networks of an
   adjacent set of co-operating network operators where traffic is
   managed to avoid congestion, rather than over the Internet where
   congestion control is required.  Usage restrictions apply to MPLS-in-
   UDP usage for traffic that is not congestion controlled and to UDP
   zero checksum usage with IPv6.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/

(Continue reading)

Loa Andersson | 31 Jan 08:10 2015
Picon

poll to see if we have consensus tp adopt draft-esale-mpls-app-aware-tldp as an MPLS wg document

Working Group,

This is to start a two week poll on adopting draft-esale-mpls-app-
aware-tldp-03 as an MPLS working group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls <at> ietf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

There is 1 IPR disclosure against this document. An IPR has been
started in parallel to the adoption poll, and the adoption
poll will not be closed before we have responses from all authors.

If you are on the the mpls working group mailing list and
aware of IPR that relates to this draft, you should respond to the
IPR poll.

This poll ends February 14, 2015.

/Loa
--

-- 

Loa Andersson                        email: loa <at> mail01.huawei.com
Senior MPLS Expert                          loa <at> pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64

_______________________________________________
mpls mailing list
mpls <at> ietf.org
(Continue reading)

Loa Andersson | 31 Jan 08:01 2015
Picon

IPR poll on draft-esale-mpls-app-aware-tldp

Working group,

An adoption poll will be started on draft-esale-mpls-app-aware-tldp.
We will run the IPR poll in parallel.

This mail starts that IPR poll.

Are you aware of any IPR that applies to draft-esale-mpls-app-
aware-tldp?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

Currently there are currently 1 IPR disclosure that relates to this
document.

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR.

*The response needs to be sent to the MPLS wg mailing list.*

The document will not advance to the next stage until a response has 
been received from each author and contributor.

If you are on the MPLS WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any
IPR that has not yet been disclosed in conformance with IETF rules.

Thanks, Loa
(Continue reading)

IETF Secretariat | 30 Jan 09:01 2015
Picon

Milestones changed for mpls WG

Changed milestone "++ Progress draft-ietf-mpls-proxy-lsp-ping to
publication", set state to active from review, accepting new
milestone.

URL: http://datatracker.ietf.org/wg/mpls/charter/

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

IETF Secretariat | 30 Jan 05:32 2015
Picon

Milestones changed for mpls WG

Changed milestone "** Progress draft-ietf-mpls-pim-sm-over-mldp to
publication", added draft-ietf-mpls-pim-sm-over-mldp to milestone.

Changed milestone "++ Progress draft-ietf-mpls-proxy-lsp-ping to
publication", added draft-ietf-mpls-proxy-lsp-ping to milestone.

URL: http://datatracker.ietf.org/wg/mpls/charter/

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

IETF Secretariat | 30 Jan 05:28 2015
Picon

Milestones changed for mpls WG

Changed milestone "Submit draft-ietf-mpls-proxy-lsp-ping fpr
publication", resolved as "Done".

URL: http://datatracker.ietf.org/wg/mpls/charter/

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

The IESG | 29 Jan 20:40 2015
Picon

Last Call: <draft-ietf-mpls-proxy-lsp-ping-03.txt> (Proxy MPLS Echo Request) to Proposed Standard

The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Proxy MPLS Echo Request'
  <draft-ietf-mpls-proxy-lsp-ping-03.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2015-02-12. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document defines a means of remotely initiating Multiprotocol
   Label Switched Protocol Pings on Label Switched Paths. A MPLS proxy
   ping request is sent to any Label Switching Routers along a Label
   Switched Path. The primary motivations for this facility are first to
   limit the number of messages and related processing when using LSP
   Ping in large Point-to-Multipoint LSPs, and second to enable leaf to
   leaf/root tracing.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-proxy-lsp-ping/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-proxy-lsp-ping/ballot/

The following IPR Declarations may be related to this I-D:

   http://datatracker.ietf.org/ipr/778/
(Continue reading)

internet-drafts | 29 Jan 19:10 2015
Picon

I-D Action: draft-ietf-mpls-proxy-lsp-ping-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

        Title           : Proxy MPLS Echo Request
        Authors         : George Swallow
                          Vanson Lim
                          Sam Aldrin
	Filename        : draft-ietf-mpls-proxy-lsp-ping-03.txt
	Pages           : 24
	Date            : 2015-01-29

Abstract:
   This document defines a means of remotely initiating Multiprotocol
   Label Switched Protocol Pings on Label Switched Paths. A MPLS proxy
   ping request is sent to any Label Switching Routers along a Label
   Switched Path. The primary motivations for this facility are first to
   limit the number of messages and related processing when using LSP
   Ping in large Point-to-Multipoint LSPs, and second to enable leaf to
   leaf/root tracing.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-proxy-lsp-ping/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mpls-proxy-lsp-ping-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-proxy-lsp-ping-03

(Continue reading)

Black, David | 28 Jan 18:34 2015

Re: Advice on draft-ietf-mpls-in-udp

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:mpls-bounces <at> ietf.org] On Behalf Of Alia Atlas
Sent: Wednesday, January 28, 2015 10:32 AM
To: Loa Andersson
Cc: mpls <at> ietf.org
Subject: Re: [mpls] Advice on draft-etf-mpls-in-udp

 

Hi Loa,

 

On Wed, Jan 28, 2015 at 1:01 AM, Loa Andersson <loa <at> pi.nu> 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:david.black <at> emc.com]
Sent: Tuesday, January 27, 2015 7:51 PM
To: Xuxiaohu
Cc: Loa Andersson; draft-ietf-mpls-in-udp <at> tools.ietf.org; adrian <at> olddog.co.uk;
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:xuxiaohu <at> huawei.com]
Sent: Monday, January 26, 2015 11:01 AM
To: Black, David
Cc: Loa Andersson; draft-ietf-mpls-in-udp <at> tools.ietf.org;
adrian <at> olddog.co.uk
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 [david.black <at> emc.com]
发送时间: 2015126 18:40
收件人: Xuxiaohu
抄送: Loa Andersson; draft-ietf-mpls-in-udp <at> tools.ietf.org;
adrian <at> olddog.co.uk; 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:xuxiaohu <at> huawei.com]
Sent: Monday, January 26, 2015 4:42 AM
To: Black, David
Cc: Loa Andersson; draft-ietf-mpls-in-udp <at> tools.ietf.org;

adrian <at> olddog.co.uk

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:david.black <at> emc.com]
Sent: Saturday, January 24, 2015 3:15 AM
To: Xuxiaohu
Cc: Loa Andersson; draft-ietf-mpls-in-udp <at> tools.ietf.org;

adrian <at> olddog.co.uk;

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:xuxiaohu <at> huawei.com]
Sent: Thursday, January 22, 2015 8:40 PM
To: Black, David
Cc: Loa Andersson; draft-ietf-mpls-in-udp <at> tools.ietf.org;
adrian <at> olddog.co.uk
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:david.black <at> emc.com]
Sent: Thursday, January 22, 2015 11:15 PM
To: Xuxiaohu
Cc: Loa Andersson; draft-ietf-mpls-in-udp <at> tools.ietf.org;

adrian <at> olddog.co.uk;

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:xuxiaohu <at> huawei.com]
Sent: Wednesday, January 21, 2015 10:22 PM
To: Black, David
Cc: Loa Andersson; draft-ietf-mpls-in-udp <at> tools.ietf.org;
adrian <at> olddog.co.uk
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:david.black <at> emc.com]
Sent: Thursday, January 22, 2015 3:17 AM
To: Eric C Rosen; Alia Atlas; Xuxiaohu
Cc: Loa Andersson; <mpls-ads <at> tools.ietf.org>;
mpls-chairs <at> tools.ietf.org;
draft-ietf-mpls-in-udp <at> tools.ietf.org;
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:erosen <at> juniper.net]
Sent: Wednesday, January 21, 2015 11:26 AM
To: Alia Atlas; Xuxiaohu
Cc: erosen <at> juniper.net; Black, David; Loa Andersson;
<mpls- ads <at> tools.ietf.org>; mpls-chairs <at> tools.ietf.org;
draft-ietf-mpls-in- udp <at> tools.ietf.org; 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: loa <at> mail01.huawei.com
Senior MPLS Expert                          loa <at> pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64

 

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Michel Gosse | 28 Jan 18:09 2015
Picon

MPLS SDN World 2015: Standards versus open source

The 17th Edition of MPLS SDN World Congress and the 4th Edition of NFV & SDN Summit, will take place in Paris next 17 to 20 March, 2015. 


The two events will share a common first day.

 

MPLS SDN World  Congress 2015: Standards versus open source, segment routing progress, resilience, protection & restoration, SDN migration, datacenter.


NFV & SDN Summit 2015:  PoCs reports, orchestration, use cases.

 

More info:

http://www.uppersideconferences.com/mpls-sdn/mpls_sdn_2015_agenda_conference_day_1.html

 

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

Gmane