Subject: [mpls] Opinion sort: [Technical Errata Reported] RFC3107 (2319)

From: Adrian Farrel <[email-masked]>
Date: Thu, 19 Aug 2010 13:23:40 +0100

Hi,

Can I have the authors'  and WG's opinion on Bruno's comments, please.

Point 1 seems reasonable to me.
Point 2 feels like a bit of  semantic issue. If MPLS packets can be
exchanged, is there not an LSP by definition?
Removing the sentence (as in Point 3) would require adding the reference,
etc. and that is a mess better handled by the new draft "updating" the RFC.

Thoughts?

Thanks,
Adrian
----- Original Message ----- 
From: "RFC Errata System" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 07, 2010 4:22 PM
Subject: [mpls] [Technical Errata Reported] RFC3107 (2319)

>
> The following errata report has been submitted for RFC3107,
> "Carrying Label Information in BGP-4".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3107&eid=2319
>
> --------------------------------------
> Type: Technical
> Reported by: Bruno Decraene <[email-masked]>
>
> Section: 5
>
> Original Text
> -------------
> "A BGP speaker should not advertise this capability to another BGP speaker
> unless there is a Label Switched Path (LSP) between the two speakers."
>
>
> Corrected Text
> --------------
> "An eBGP speaker should not advertise this capability to another eBGP
> speaker unless there is a Label Switched Path (LSP) or layer two interface
> between the two speakers."
>
> Or just remove completely that sentence.
>
> Notes
> -----
> 1) :s/BGP/eBGP
> An iBGP router should be able to set up an internal BGP session for AFI 1
> / SAFI 4 toward a Route Reflector even if the Route Reflector is not
> capabble of forwarding MPLS packets (This case is even described in the
> section 2 of the RFC)
>
> 2) + layer two interface
> If both router are connected by a direct (sub)interface, they should be
> able to exchange MPLS packets even if there is no LSP between them.
>
> 3) Remove the sentence
> AFAIK, the point is now better addressed by
> draft-ietf-idr-bgp-bestpath-selection-criteria-01.txt
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC3107 (draft-ietf-mpls-bgp4-mpls-04)
> --------------------------------------
> Title               : Carrying Label Information in BGP-4
> Publication Date    : May 2001
> Author(s)           : Y. Rekhter, E. Rosen
> Category            : PROPOSED STANDARD
> Source              : Multiprotocol Label Switching
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Eric Rosen <[email-masked]>
Date: Thu, 19 Aug 2010 11:27:52 -0400

Adrian> Can I have the authors' and WG's opinion on Bruno's comments,
Adrian> please.

It's possible to go through any document and find something that could have
been stated more precisely, but when a document has been around for ten
years without misleading anyone, it's usually better just to let it be.

The suggested fixes are no more correct than the original text.

- The EBGP/IBGP distinction is not relevant here, as this does not properly
  capture the notion of whether a BGP speaker is in the data path.

- The ability to send an MPLS packet from one router to another does not
  necessarily depend on there being either a sequence of MPLS routers
  between them or on there being an L2 connection between them.  There might
  be an L3 tunnel, for example.

If you are asking whether the errata should be "accepted" (whatever that
means exactly), I'd have to say no.  That does not seem like a proper way of
making a technical correction, the correction isn't really correct anyway,
and it's hard to imagine anyone being seriously misled by this bit of text.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 20 Aug 2010 12:11:34 +0100

Thanks Eric,

Useful answer. I'll reject the erratum.

Cheers,
Adrian

---

From: Yakov Rekhter <[email-masked]>
Date: Sun, 22 Aug 2010 08:08:30 -0700

Adrian,

> etc. and that is a mess better handled by the new draft "updating" the RFC.

Let me propose Point 1', namely just remove completely that sentence.

Yakov.