Re: [bess] Rtgdir last call review of draft-ietf-bess-mvpn-expl-track-09

[Carlos Pignataro (cpignata)]

Hi, Eric,

On Sep 13, 2018, at 9:52 AM, Eric C Rosen 
mailto:ero...@juniper.net>> wrote:

On 9/12/2018 11:26 PM, Carlos Pignataro wrote:
I found the rational and specific details on what this document "Updates" from
three previous RFCs to be lacking, and confusing.

Carlos,

Thanks for your review.

Anytime!


I don't want to get caught up in the neverending discussion of exactly what 
constitutes an "Update".  This is being discussed right now on the IETF list, 
and it's quite clear that there is no consensus.  As usual, every possible 
opinion is dogmatically held by someone ;-)

I agree — I support a pragmatic approach.

Someone reading RFC 6514 today will find nine RFCs updating it — with an 
aggregate of 186 pages (not including this document). The simpler that we can 
make the forward-linkage, the higher likelihood of people actually reading and 
robustly and interoperably implementing. No dogma or religion here. Simply, 
there’s a cost to spec complexity.


The introduction of the expl-track draft explicitly points out a number of 
situations that are not adequately addressed in the prior RFCs, and for which 
the prior RFCs do not provide clear guidance. This is a potential source of 
interoperability problems.

The introduction also indicates a number of new features that are added by the 
draft.

I agree that the Introduction section includes prose (and a bullet list) 
describing an intro as well as current shortcomings and new features. And from 
here the updates can mostly be inferred.


Anyone implementing RFCs 6514, 6625, and/or 7524 will certainly be well-advised 
to read this draft in order to (a) make sure that they properly handle the 
situations that are not explicitly addressed by the prior RFCs, and (b) to make 
sure that they are aware of the new features so they can make an informed 
decision of whether to implement them.

Indeed. She or he will be also well-advised to read other nine RFCs. And figure 
out how they are relevant to the code at hand.


I think this justifies the "Updates" status.

I agree it justifies the Updates status. I agree with the labeling of Updates 
for expl-track, as well as with the semantics of “read this too”.

I am simply suggesting, for your (plural) consideration, to be more explicit 
about what exactly is being updated in each case for each RFC being Updated.


I recommend an "Updates from RFC XYZ" section in which there is a textual
explanation and ideally Old/New specifics on how this document updates previous
RFCs.

I think the introduction covers this in the appropriate level of detail; I 
really don't know what could be added.


For your (plural) consideration, a new section titled “Updated RFCs” with three 
sub-sections, one for each RFC being updated, with a list of what is updated.

Eric


—
Carlos Pignataro, car...@cisco.com<mailto:car...@cisco.com>

“Sometimes I use big words that I do not fully understand, to make myself sound 
more photosynthesis."


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Rtgdir last call review of draft-ietf-bess-mvpn-expl-track-09

[Carlos Pignataro]

Reviewer: Carlos Pignataro
Review result: Has Nits

This is a very well written and detailed document.

I have only one concern, which I believe should be addressed before moving this
document forward:

I found the rational and specific details on what this document "Updates" from
three previous RFCs to be lacking, and confusing.

I recommend an "Updates from RFC XYZ" section in which there is a textual
explanation and ideally Old/New specifics on how this document updates previous
RFCs. At least, something more inline with current thinking as per
https://www.ietf.org/mail-archive/web/ietf/current/msg109106.html

Thanks,

Carlos Pignataro.

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Opsdir telechat review of draft-ietf-bess-evpn-etree-13

[Carlos Pignataro]

Reviewer: Carlos Pignataro
Review result: Ready

Thank you for considering and addressing all the comments and requests from my
previous OpsDir review of -12!

Carlos Pignataro.

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Opsdir last call review of draft-ietf-bess-evpn-etree-12

[Carlos Pignataro (cpignata)]

Thanks Ali. General Ack to all your responses, make sense.

A follow-up question, though:

I notice “Reserved” in a few places. For example in Figure 4, which seems to 
make sense as the Reserved is a Must Be Zero (MBZ)

However, on the Flags, it says:

  0 1 2 3 4 5 6 7
 +-+-+-+-+-+-+-+-+
 |  reserved   |L|
 +-+-+-+-+-+-+-+-+

…

 Initial registrations are as follows:

 bit   Name Reference

 0-6   Reserved This document
 7 Leaf-Indication  This document

Do you mean “Reserved” for the unassigned bit flags, or “Unassigned” (see the 
different in RFC 8126).

Finally, in the sentence:

   The reserved bits should be set to zero by the transmitter and should
   be ignored by the receiver.

Do those two “should” mean “should”, “SHOULD”, or “MUST”?

Thanks!

Carlos.

On Aug 16, 2017, at 8:54 PM, Ali Sajassi (sajassi) 
<saja...@cisco.com<mailto:saja...@cisco.com>> wrote:


Hi Carlos,

Thanks for your review and comments. Please see inline for my responses.

On 8/7/17, 2:46 PM, "Carlos Pignataro (cpignata)" 
<cpign...@cisco.com<mailto:cpign...@cisco.com>> wrote:

Reviewer: Carlos Pignataro
Review result: Has Issues

Reviewer: Carlos Pignataro
Review result: Has Nits (and one potential Issue)

I am the OPS-DIR reviewer and in general I do not have operational concerns
with this document.

The main issue I have is in regards to the redefinition of the MSB of the
Tunnel Type, and associated backwards/forward compatibility considerations.

I note that RFC 7385 is Normatively referenced by a number of I-Ds:
https://datatracker.ietf.org/doc/rfc7385/referencedby/
BUT draft-ietf-bess-evpn-etree is not:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree/referencedby/

So would those former be pointing to old info? And what other Backwards Compat
considerations are there?

To maximize backward/forward compatibility, let's retain the value for 
"Experimental Use” and “Reserved” as before per [RFC7385] and reduce the range 
for Composite tunnel for this draft. So, the changes will be
From existing IANA assignments:
0x0C - 0xFA Unassigned
0xFB - 0xFE Experimental [RFC7385]
0xFF Reserved [RFC7385]
To:
  0x0C – 0x3F Unassigned
  0x80 – 0xBF reserved for composite tunnel
  0xD0 – 0xFA Unassigned
  0xFB - 0xFE Experimental [RFC7385]
  0xFF  Reserved [RFC7385]



Further, some nits and editorials for your consideration:

   The Metro Ethernet Forum (MEF) has defined a rooted-multipoint
   Ethernet service known as Ethernet Tree (E-Tree). A solution
   framework for supporting this service in MPLS networks is proposed in
   RFC7387 ("A Framework for Ethernet Tree (E-Tree) Service over a
   Multiprotocol Label Switching (MPLS) Network").

Proposed? Or Described / Defined?
OK, changed to “described"

Same comment for the first sentence of the second paragraph of the Intro.
Changed to “describes"

   This document makes use of the
   most significant bit of the scope governed by the IANA registry
   created by RFC7385, and hence updates RFC7385 accordingly.

RFC 7385 does not mention a "scope". This really talks about the Tunnel Type.
Please reword for unambiguous clarity.

Changed it to “This document makes use of the most significant bit of the PMSI 
tunnel type governed by the IANA …"

3.1 Known Unicast Traffic

   To support the above ingress filtering functionality, a new E-TREE
   Extended Community with a Leaf indication flag is introduced [section
   5.2]. This new Extended Community MUST be advertised with MAC/IP

Section 5.2 is not a referenced citation.

Changed it to “[5.1]”. Nice catch! Thanks.

Similar issue with [5.1] at:

   In PBB-EVPN, the PE advertises a Root/Leaf indication along with each
   B-MAC Advertisement route, to indicate whether the associated B-MAC
   address corresponds to a Root or a Leaf site. Just like the EVPN
   case, the new E-TREE Extended Community defined in section [5.1] is
   advertised with each MAC Advertisement route.

This paragraph refers to the correct section!

3.2 BUM Traffic

Please expand to Broadcast, Unkonwn, Multicast.

Done.

   When receiver ingress-replication label is needed, the high-order bit
   of the tunnel type field (Composite Tunnel bit) is set while the
   remaining low-order seven bits indicate the tunnel type as before.

I believe it would be useful to depict the Composite Tunnel bit in Figure 5 as
well... It's not only a 1-octet Type.

I believe the description is clear in the text and adding additional diagram 
and text to describe the diagram would make it too verbose.

Also, please note:

  ** Obsolete normative reference: RFC 5226

Changed it to RFC 8126.

  ** Downref: Normative reference to an Informational RFC: RFC 7387

That’s OK.

Thanks again for your review,
Ali


Thank you!

Carlos.



__

[bess] Opsdir last call review of draft-ietf-bess-evpn-etree-12

[Carlos Pignataro]

Reviewer: Carlos Pignataro
Review result: Has Issues

Reviewer: Carlos Pignataro
Review result: Has Nits (and one potential Issue)

I am the OPS-DIR reviewer and in general I do not have operational concerns
with this document.

The main issue I have is in regards to the redefinition of the MSB of the
Tunnel Type, and associated backwards/forward compatibility considerations.

I note that RFC 7385 is Normatively referenced by a number of I-Ds:
https://datatracker.ietf.org/doc/rfc7385/referencedby/
BUT draft-ietf-bess-evpn-etree is not:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree/referencedby/

So would those former be pointing to old info? And what other Backwards Compat
considerations are there?

Further, some nits and editorials for your consideration:

   The Metro Ethernet Forum (MEF) has defined a rooted-multipoint
   Ethernet service known as Ethernet Tree (E-Tree). A solution
   framework for supporting this service in MPLS networks is proposed in
   RFC7387 ("A Framework for Ethernet Tree (E-Tree) Service over a
   Multiprotocol Label Switching (MPLS) Network").

Proposed? Or Described / Defined?

Same comment for the first sentence of the second paragraph of the Intro.

   This document makes use of the
   most significant bit of the scope governed by the IANA registry
   created by RFC7385, and hence updates RFC7385 accordingly.

RFC 7385 does not mention a "scope". This really talks about the Tunnel Type.
Please reword for unambiguous clarity.

3.1 Known Unicast Traffic

   To support the above ingress filtering functionality, a new E-TREE
   Extended Community with a Leaf indication flag is introduced [section
   5.2]. This new Extended Community MUST be advertised with MAC/IP

Section 5.2 is not a referenced citation.

Similar issue with [5.1] at:

   In PBB-EVPN, the PE advertises a Root/Leaf indication along with each
   B-MAC Advertisement route, to indicate whether the associated B-MAC
   address corresponds to a Root or a Leaf site. Just like the EVPN
   case, the new E-TREE Extended Community defined in section [5.1] is
   advertised with each MAC Advertisement route.

3.2 BUM Traffic

Please expand to Broadcast, Unkonwn, Multicast.

   When receiver ingress-replication label is needed, the high-order bit
   of the tunnel type field (Composite Tunnel bit) is set while the
   remaining low-order seven bits indicate the tunnel type as before.

I believe it would be useful to depict the Composite Tunnel bit in Figure 5 as
well... It's not only a 1-octet Type.

Also, please note:

  ** Obsolete normative reference: RFC 5226

  ** Downref: Normative reference to an Informational RFC: RFC 7387

Thank you!

Carlos.


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] I-D Action: draft-ietf-idr-tunnel-encaps-01.txt

[Carlos Pignataro (cpignata)]

Eric,

Thanks for the response — please find some follow-ups inline.

> On Feb 15, 2016, at 12:22 PM, Eric C Rosen <ero...@juniper.net> wrote:
> 
> On 2/11/2016 6:38 PM, Carlos Pignataro (cpignata) wrote:
>> Hi, Eric,
>> 
>> Thanks for sending this out — I am interested in this document, and will 
>> give it a critical review (in particular the sections you call out below).
> Thanks!
>> 
>> In the mean time, however, I wanted to send a few high-level comments 
>> (prepended with “CMP”) from scanning through it. I hope these are useful.
>> 
>> 3.2.  Encapsulation Sub-TLVs for Particular Tunnel Types
>> 
>>This section defines Tunnel Encapsulation sub-TLVs for the following
>>tunnel types: VXLAN ([RFC7348]), VXLAN-GPE ([VXLAN-GPE]), NVGRE
>>([RFC7637]), GTP ([GTP-U]), MPLS-in-GRE ([RFC2784], [RFC2890],
>>[RFC4023]), L2TPv3 ([RFC3931]), and GRE ([RFC2784], [RFC2890],
>>[RFC4023]).
>> 
>> 
>> CMP: More comments below, but I am a bit confused about the need to include 
>> MPLS-in-GRE, and the lack of IP-in-IP (Tunnel Type 7) for example.
> MPLS-in-GRE is included in section 3.2 because there is already a tunnel type 
> codepoint allocated for it, and if that tunnel type is used, an encapsulation 
> sub-TLV is needed in order to signal the GRE key.
> 
> One can argue that there is no need for the MPLS-in-GRE tunnel type, since 
> everything you can do with it could be done instead with the GRE tunnel type. 
>  But unless and until we decide to deprecate the MPLS-in-GRE tunnel type, it 
> needs to be included.In theory, I would love to see the MPLS-in-GRE 
> tunnel type deprecated, but I worry that that might introduce a backwards 
> compatibility problem.This is certainly something that can be discussed 
> by the WG.
> 

I agree — and would welcome that discussion as well.

> IP-in-IP is not mentioned in section 3.2 because, although there is a tunnel 
> type codepoint allocated for it, no one has ever defined an encapsulation 
> sub-TLV for it.  Also, if it is necessary to signal values for the fields of 
> the outer iP header, it might make more sense to use an "outer encapsulation 
> sub-TLV" (section 3.3).  Do you have an opinion about this?

You are right, Section 3.2 is indeed about the sub-TLVs. I believe I was 
reacting to IP-in-IP not being mentioned anywhere (other than briefly in the 
IANA section).

Perhaps I was expecting something like this, although I agree with you it’s a 
no-op:

3.2.x. IP-in-IP

   This document does not defines an encapsulation sub-TLV for IP-in-IP tunnels.
   When the tunnel type is IP-in-IP, the encapsulation sub-TLV MUST NOT be used.

Now, IP-in-IP and other tunnels (like for example MPLS-over-UDP) present an 
interesting question (that you raise above): In these, is the encapsulation IP 
and UDP, or is this a null encapsulation with an outer encapsulation of IP and 
UDP?

To me, the pragmatic case is to use the Outer encapsulation sub-TLV for IP 
fields in IP-in-IP, and for UDP fields in MPLS-over-UDP.

However, if the Tunnel Type is IP-in-IP (7), then using an Outer-encapsulation 
sub-TLV would imply IP-in-IP-in-IP. Is IP-in-IP a null tunnel type with outer 
encapsulation and with protocol = 0x0800? No. It is an IP-in-IP tunnel type. No 
protocol (since the tunnel encap constraints it to IP), and no outer encap. It 
is not “further encapsulated inside UDP and/or IP” as the text in section 1.3

It would certainly help to explain this explicitly.

It gets equally interesting with MPLS-over-UDP, because “UDP” is not a tunnel 
type specified just yet, which could be used with MPLS protocol type sub-TLV. 
Or a more limiting and duplicative MPLS-in-UDP tunnel type.  What tunnel type 
is used there? null encap? protocol type sub-TLV?

One additional comment — I could not figure out the sorting order for the 
encapsulations in subsections 3.2.x. I would consider sorting by tunnel type 
value in ascending order, and starting each sub-section with a “This 
encapsulation sub-TLV is used when the Tunnel Type is XYZ (numerical value)"

>> 
>> CMP: A couple of editorial comments as well: For GRE, I think you also need 
>> to cite RFC 7676 (GRE over IPv6)
> Sure.

Thank you.

>> 
>> CMP: Also, having this document Obsolete RFC 5512 effectively also orphans a 
>> number of Tunnel types and sub-TLVs. For example, Tunnel Types values 3-6 
>> from RFC 5566 (IPsec Tunnel Encap) and IPsec Tunnel Authenticator sub-TLV. I 
>> do not know if the answer is to also have that incorporated (useful parts as 
>> you say) and obsoleted. Maybe not, maybe it does make sense given it is a 
>> short doc, which would lead to a complete self-contained set of Tunnel types.
> I think RFC 5566 will have to be obsoleted an

Re: [bess] I-D Action: draft-ietf-idr-tunnel-encaps-01.txt

[Carlos Pignataro (cpignata)]

Hi, Eric,

Thanks for sending this out — I am interested in this document, and will give 
it a critical review (in particular the sections you call out below).

In the mean time, however, I wanted to send a few high-level comments 
(prepended with “CMP”) from scanning through it. I hope these are useful.

3.2.  Encapsulation Sub-TLVs for Particular Tunnel Types

   This section defines Tunnel Encapsulation sub-TLVs for the following
   tunnel types: VXLAN ([RFC7348]), VXLAN-GPE ([VXLAN-GPE]), NVGRE
   ([RFC7637]), GTP ([GTP-U]), MPLS-in-GRE ([RFC2784], [RFC2890],
   [RFC4023]), L2TPv3 ([RFC3931]), and GRE ([RFC2784], [RFC2890],
   [RFC4023]).


CMP: More comments below, but I am a bit confused about the need to include 
MPLS-in-GRE, and the lack of IP-in-IP (Tunnel Type 7) for example.

CMP: A couple of editorial comments as well: For GRE, I think you also need to 
cite RFC 7676 (GRE over IPv6)

CMP: Also, having this document Obsolete RFC 5512 effectively also orphans a 
number of Tunnel types and sub-TLVs. For example, Tunnel Types values 3-6 from 
RFC 5566 (IPsec Tunnel Encap) and IPsec Tunnel Authenticator sub-TLV. I do not 
know if the answer is to also have that incorporated (useful parts as you say) 
and obsoleted. Maybe not, maybe it does make sense given it is a short doc, 
which would lead to a complete self-contained set of Tunnel types.

3.2.4.  L2TPv3
…
  Cookie: an optional, variable length (encoded in octets -- 0 to 8
  octets) value used by L2TPv3 to check the association of a

CMP: The cookie can only take sizes 0, 4, or 8 octets, and not 0..8

3.2.7.  MPLS-in-GRE

CMP: This seems to be an example and not a separate encapsulation type. This is 
GRE Type, with MPLS as protocol sub-TLV. I see that the section says:

   While it is not really necessary to have both the GRE and MPLS-in-GRE
   tunnel types, both are included for reasons of backwards
   compatibility.

CMP: I will also note that having two different ways of doing the same thing 
(Tunnel Type 2 and protocol 0x8847 vs. Tunnel Type 11) takes us away from 
interop., and that there does not seem to be MPLS-in-GRE defined in any RFC (so 
it seems like potentially a good time to rationalize instead of perpetuate). My 
$0.02 only.

CMP: Should MPLS-over-GRE be an example only? Or otherwise, how do we interop 
the two types of “ MPLS-over-GRE”? Should an example be also added about 
MPLS-over-L3TPv3?

3.3.1.  IPv4 DS Field

CMP: Why not also define this for IPv6?

3.3.2.  UDP Destination Port

CMP: One additional thought. Obsoleting RFC 5512 also removes the anchor from 
RFC 5640 — that is not a terrible deal in itself, but is there also an 
opportunity to generalize the Load-Balancing approach thereby defined to also 
include the new encapsulations’ LB, UDP-based (port as the LB Field), etc?

I hope these are clear and useful — Thanks!

— Carlos.


> On Dec 28, 2015, at 10:20 AM, Eric C Rosen  wrote:
> 
> The -01 revision of draft-ietf-idr-tunnel-encaps has the following changes 
> from the -00 revision:
> 
> - By popular request, it has been written in such a way as to obsolete 
> RFC5512.  This means that anything useful in RFC5512 had to be incorporated 
> into the new draft.  I would welcome opinions on whether this was done 
> correctly.
> 
> - Two new sub-TLVs are specified:  "MPLS Label Stack" and "Prefix-SID".  I 
> would welcome opinions on whether these are useful or not.  (I'm pretty sure 
> that the first is useful, the second is more speculative.)
> 
> - If you are familiar with deployed uses of the Encapsulation Extended 
> Community, the Color Extended Community, or the Router's MAC Extended 
> Community, it may be worth checking section 4 to make sure that the draft 
> does not introduce any problems.
> 
> - I wish more folks would take a critical look at section 8, which is 
> primarily about the use of VXLAN/NVGRE/VXLAN-GPE together with labeled 
> address families.
> 
> I would also be interested in hearing if anyone has an opinion on the utility 
> of using this sort of mechanism to signal IPsec tunnels.  Once RFC 5512 is 
> obsoleted, RFC 5566 ("BGP IPsec Tunnel Encapsulation Attribute") will need to 
> be revised.  It might be possible to generalize that in such a way as to 
> facilitate the secure interconnection of two private ASes across the public 
> Internet.  Comments on whether RFC 5566 takes a reasonable approach would be 
> welcome.
> 
> 
> 
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [mpls] [Editorial Errata Reported] RFC7510 (4350)

[Carlos Pignataro (cpignata)]

Ross,

I agree with the reasoning you lay out — but I would add that there is a 
difference between updating an IANA registry with an extra citation (mostly 
harmless, possibly useful), versus updating a Standards Track RFC with an 
Erratum. I would further add that a reference description for how to use the 
Tunnel Type 13 is still missing, as RFC 7510 does not accomplish that.

Thanks!

— Carlos (speaking as Carlos)

 On Apr 29, 2015, at 5:22 PM, Ross Callon rcal...@juniper.net wrote:
 
 I may be a bit confused here regarding what sort of references are intended 
 to be listed in the registry.
 
 Looking at the “Border Gateway Protocol (BGP) Parameters”, and scrolling down 
 to “BGP Tunnel Encapsulation Attribute Tunnel Types”, I see entries for 
 various encapsulation types with various references. As some examples:
 
 For the GRE tunnel type, I see a reference to RFC5512. RFC 5512 is “The BGP 
 Encapsulation SAFI and the BGP Tunnel Encapsulation Attribute”, and is 
 specifically not the RFC that defines GRE.
 
 For the IPsec in Tunnel-mode tunnel type, I see a reference to RFC 5566. 
 Again RFC 5566 is not the RFC that specifies IPsec in Tunnel-mode.
 
 For the VXLAN tunnel type, I see a reference to draft-sd-l2vpn-evpn-overlay. 
 One issue is that this is an out of date reference 
 (draft-sd-l2vpn-evpn-overlay has been replaced by 
 draft-ietf-bess-evpn-overlay). More importantly, this again is not the 
 document that defines VXLAN. Rather, draft-ietf-bess-evpn-overlay talks about 
 how to use various encapsulations (of which VXLAN is one) along with BGP 
 signaling to accomplish something.
 
 Thus to me, referencing RFC 7510 in this particular registry is not the same 
 sort of reference that is included along with the other tunnel types. 
 However, I don’t see any problem with referencing the document that defines 
 the tunnel method as an additional reference for each entry. If we are going 
 to do this then perhaps we (for some definition of “we”) should also add 
 other references to the registry, specifically the document that defines the 
 tunnel mechanism for each of the other tunnel types.
 
 Ross (speaking as co-author of RFC 7510)
 
 From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com]
 Sent: Wednesday, April 29, 2015 3:25 PM
 To: Xiaohu Xu
 Cc: Adrian Farrel; Loa Andersson; RFC Errata System; Nischal Sheth; Lucy 
 yong; Ross Callon; Black, David; Alia Atlas; BRUNGARD, DEBORAH A; Alvaro 
 Retana (aretana); George Swallow (swallow); m...@ietf.org; bess@ietf.org
 Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350)
 
 Hi Xiaohu,
 
 On Apr 29, 2015, at 4:40 AM, Xuxiaohu xuxia...@huawei.com 
 mailto:xuxia...@huawei.com wrote:
 
 Hi Carlos,
 
 
 -Original Message-
 From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com 
 mailto:cpign...@cisco.com]
 Sent: Wednesday, April 29, 2015 2:58 AM
 To: Adrian Farrel
 Cc: Loa Andersson; RFC Errata System; Xuxiaohu; nsh...@juniper.net 
 mailto:nsh...@juniper.net; Lucy
 yong; Ross Callon; Black, David; Alia Atlas; BRUNGARD, DEBORAH A; Alvaro
 Retana (aretana); George Swallow (swallow); m...@ietf.org 
 mailto:m...@ietf.org
 Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350)
 
 Hi, Adrian,
 
 Thanks for the additional context. Note that I did not object any changes made
 to the registry itself (although I still think that pointing to RFC 7510 is 
 incorrect),
 only to the errata. Modifying the data plane document to include an IANA 
 action
 for BGP sounds off.
 
 In other words, I see two problems with the approach from the errata (or 
 really
 two sides of the same issue):
 
 1. RFC 7510 specifies the data plane encapsulation, and not the BGP 
 signaling. As
 such, it does not make for a good reference for the BGP Tunnel Encapsulation
 Attribute Tunnel Type 13.
 
 2. Existing entries in the BGP Tunnel Encapsulation Attribute Tunnel Types
 registry point to the documents which specify how that attribute is used.
 
 For example, the value 1, L2TPv3 over IP, points to RFC 5512 and not to RFC
 3931. The value 2, GRE, points to RFC 5512 and not to RFC 2784. The value 4
 points to RFC 5566 and not to RFC4302, RFC4303.
 
 In fact, I had ever followed the above logic by specifying the BGP signaling 
 for MPLS-in-UDP in a separate doc 
 (https://tools.ietf.org/html/draft-xu-softwire-encaps-udp-00 
 https://tools.ietf.org/html/draft-xu-softwire-encaps-udp-00) which has been 
 moved to BESS WG (see https://tools.ietf.org/html/draft-xu-bess-encaps-udp-00 
 https://tools.ietf.org/html/draft-xu-bess-encaps-udp-00) recently. However…
 
 
 I am not implying that a new I-D is necessarily required. I am saying that:
 1. It seems a step was skipped with this Errata, where a BGP parameter points 
 to a data plane definition, and
 2. It appears to be technically incorrect, since there are two potential 
 modes (with and without DTLS) but one entry only.
 
 Thanks,
 
 — Carlos.
 
 
 Best regards,
 Xiaohu
 
 
 There is another

Re: [bess] [mpls] [Editorial Errata Reported] RFC7510 (4350)

[Carlos Pignataro (cpignata)]

Hi Xiaohu,

 On Apr 29, 2015, at 4:40 AM, Xuxiaohu xuxia...@huawei.com wrote:
 
 Hi Carlos,
 
 -Original Message-
 From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com 
 mailto:cpign...@cisco.com]
 Sent: Wednesday, April 29, 2015 2:58 AM
 To: Adrian Farrel
 Cc: Loa Andersson; RFC Errata System; Xuxiaohu; nsh...@juniper.net 
 mailto:nsh...@juniper.net; Lucy
 yong; Ross Callon; Black, David; Alia Atlas; BRUNGARD, DEBORAH A; Alvaro
 Retana (aretana); George Swallow (swallow); m...@ietf.org 
 mailto:m...@ietf.org
 Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350)
 
 Hi, Adrian,
 
 Thanks for the additional context. Note that I did not object any changes 
 made
 to the registry itself (although I still think that pointing to RFC 7510 is 
 incorrect),
 only to the errata. Modifying the data plane document to include an IANA 
 action
 for BGP sounds off.
 
 In other words, I see two problems with the approach from the errata (or 
 really
 two sides of the same issue):
 
 1. RFC 7510 specifies the data plane encapsulation, and not the BGP 
 signaling. As
 such, it does not make for a good reference for the BGP Tunnel Encapsulation
 Attribute Tunnel Type 13.
 
 2. Existing entries in the BGP Tunnel Encapsulation Attribute Tunnel Types
 registry point to the documents which specify how that attribute is used.
 
 For example, the value 1, L2TPv3 over IP, points to RFC 5512 and not to RFC
 3931. The value 2, GRE, points to RFC 5512 and not to RFC 2784. The value 4
 points to RFC 5566 and not to RFC4302, RFC4303.
 
 In fact, I had ever followed the above logic by specifying the BGP signaling 
 for MPLS-in-UDP in a separate doc 
 (https://tools.ietf.org/html/draft-xu-softwire-encaps-udp-00 
 https://tools.ietf.org/html/draft-xu-softwire-encaps-udp-00) which has been 
 moved to BESS WG (see https://tools.ietf.org/html/draft-xu-bess-encaps-udp-00 
 https://tools.ietf.org/html/draft-xu-bess-encaps-udp-00) recently. However…
 

I am not implying that a new I-D is necessarily required. I am saying that:
1. It seems a step was skipped with this Errata, where a BGP parameter points 
to a data plane definition, and
2. It appears to be technically incorrect, since there are two potential modes 
(with and without DTLS) but one entry only.

Thanks,

— Carlos.

 Best regards,
 Xiaohu
 
 There is another technical problem with the current approach: RFC 7510
 specifies two UDP ports, for MPLS-in-UDP and MPLS-in-UDP with DTLS
 respectively. To which one of these two does the BGP Tunnel Encapsulation
 Attribute Tunnel Type value of 13 correspond to? Do you actually need two
 Types? Further, do you need to consider the LB from RFC 5640?
 
 Please see more inline.
 
 On Apr 28, 2015, at 8:34 AM, Adrian Farrel adr...@olddog.co.uk wrote:
 
 Hi Carlos,
 
 Since I raised the issue...
 
 The text that was omitted was agreed for inclusion between the RFC
 Editor, IANA, and responsible AD before the publication of the RFC,
 but was fumbled by the RFC Editor.
 
 The RFC Editor requested this report to be submitted to resolve this
 issue, and I checked with the ADs before I posted it.
 
 The problem it solves is that the existing registry entry points at an
 I-D that caused the allocation of the code point, but that I-D is not
 a good reference for explaining what MPLS in UDP is. This document
 provides a better indication.
 
 
 The reference should not explain what MPLS in UDP is. The reference should
 explain what is the BGP Tunnel Encapsulation Attribute Tunnel Type 13 for 
 MPLS
 in UDP.
 
 You said...
 
 RFC 7510 states that it ³specifies an IP-based encapsulation for
 MPLS, called MPLS-in-UDP² but there is no mention to the
 specification of any signaling associated to setting up said
 encapsulation. In other words, it self-concerns itself with the encap.
 
 That is correct. And there is no attempt to define any signaling or
 add any mention of signaling to this document.
 
 This is not a forward pointer, but a request to include a backward
 pointer. That is, it is a request to update the entry that already
 exists in the registry with a pointer to this document so that people
 can see what MPLS in UDP is when they encounter the value in the registry.
 
 
 I understand. My comment is that the reference should not be to MPLS in
 UDP. The same way that the Type 1 does not point to RFC 3931.
 
 Further, there is no mention in RFC 7510 of ³BGP² and no reference to
 RFC 5512. For a document specifying a BGP Tunnel Encapsulation
 Attribute Tunnel Type, I¹d expect a reference (normative) to RFC 5512
 (such as in RFC 5566).
 
 This document does not specify a BGP Tunnel Encapsulation Attribute
 and there is no request for it to make such a specification.
 
 References could be included, but they would be pointless because
 there is nothing to hook the references to. The *only* change
 requested is to attach a pointer to the existing entry in the registry.
 
 Lastly, the IANA page points to a different document:
 http