Re: [Idr] Additional comment period for draft-ietf-idr-tunnel-encaps-12.txt [was: Re: I-D Action: draft-ietf-idr-tunnel-encaps-12.txt]

[Linda Dunbar <[e-mail]>]

John,

Thank you very much for the explanation. Make sense. I didn’t know why need to have the statement there (without your explanation)

I will wait for the authors for the other questions I had in the email:

1.         When a client route can egress multiple egress ports (each with different IP addresses), does the Tunnel-Encap allow multiple "Remote-endpoint" SubTLV to be attached one UPDATE?



2.         In RFC5512, the BGP speaker indicates the originating Interface address in the NLRI (section 3):


[cid:image001.png@01D51D20.54C4CBC0]

draft-ietf-idr-tunnel-encaps-11  no longer has the BGP speaker originating the update. Is it intended? If Yes, does it mean that it allows a third party (which could be malicious entity) to inject routes on behalf of a legitimate router (but RFC5512 doesn’t)?  Why add this scenario? How to address the security threats introduced? If it is a conscious decision, should have some text to explain why and how to mitigate the security threats introduced.

3.

Thanks, Linda


From: John Scudder <[e-mail]>
Sent: Friday, June 07, 2019 10:49 AM
To: Linda Dunbar <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: Re: [Idr] Additional comment period for draft-ietf-idr-tunnel-encaps-12.txt [was: Re: I-D Action: draft-ietf-idr-tunnel-encaps-12.txt]

Shifting hats to a plain old working group member, I think I know the answer to this one, though:

"2.      Section 3.1 Page 10: The last paragraph states that if "Remote-Endpoint sub-TLV contains address is valid but not reachable, and the containing TLV is NOT be malformed ..". Why a address not reachable is considered as "Not Malformed”?”

Normally what we mean by “malformed” is that there’s something syntactically wrong. But of course in any default-free network, an address can be unreachable even though it’s syntactically correct — it just means that address isn’t covered by a route in the routing table. Furthermore an address can change statuses from unreachable to reachable and back again over time. It would be quite odd for a message that was considered well-formed (because the address it contained was reachable) were to later change to being considered malformed, some time after it was already received and propagated (because the route to the address it contained was withdrawn from the IGP for example).

In going back and re-reading the last paragraph of section 3.1, I find it easy to understand, I can’t think of any changes that would improve its clarity. I do note that the paragraph got simplified a little in version -12, possibly as a result of shepherd review, though it still has the “not malformed” text. The revised paragraph:

   If the Remote Endpoint sub-TLV contains an IPv4 or IPv6 address that
   is valid but not reachable, the sub-TLV is NOT considered to be
   malformed.

Regards,

—John


On Jun 7, 2019, at 11:46 AM, John G. Scudder <[e-mail]<mailto:[e-mail]>> wrote:

Thanks for your followup, Linda. I will wait on advancing the document until the authors have addressed your questions. I’ve added them to the to: line.

—John

On Jun 7, 2019, at 11:35 AM, Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:

John,

I don't think anyone has addressed my questions and comments to this draft:

https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_idr_DFj4eZO5S9lboysWIn5GygDyRv8&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=zlNlU1fIrzLHsR8ptaoICogwrs4z3YR3MSw_Pr3BY-s&s=mK-tEP7LOV8UwFC3KYqXoGzqcl4-tUxxAo3D3VyENgM&e=<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__mailarchive.ietf.org_arch_msg_idr_DFj4eZO5S9lboysWIn5GygDyRv8%26d%3DDwIGaQ%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DhLt5iDJpw7ukqICc0hoT7A%26m%3DzlNlU1fIrzLHsR8ptaoICogwrs4z3YR3MSw_Pr3BY-s%26s%3DmK-tEP7LOV8UwFC3KYqXoGzqcl4-tUxxAo3D3VyENgM%26e%3D&data=02%7C01%7Cldunbar%40futurewei.com%7C5b5c33ebdca54485945408d6eb5fba66%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636955193727074632&sdata=7qljcd%2FfWwVkmPMsWsw2TE70EyMtHp5Z0yAv29VfCMc%3D&reserved=0>

I am still waiting.

Linda Dunbar

-----Original Message-----
From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of John Scudder
Sent: Friday, June 07, 2019 10:29 AM
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] Additional comment period for draft-ietf-idr-tunnel-encaps-12.txt [was: Re: I-D Action: draft-ietf-idr-tunnel-encaps-12.txt]

The additional comment period has concluded with no further discussion. We’ll continue with sending the spec to the IESG for advancement to RFC.

Regards,

—John


On May 31, 2019, at 5:33 AM, John Scudder <jgs=[e-mail]<mailto:jgs=[e-mail]>> wrote:

As a reminder, this additional comment period has one more week to go. I haven’t seen any comments yet, which is fine since the document already passed WGLC so in this case, “silence gives consent”.

Regards,

—John


On May 23, 2019, at 3:17 PM, John Scudder <jgs=[e-mail]<mailto:jgs=[e-mail]>> wrote:

Hi All,

This is an update for a draft that has passed WGLC. I have been acting as document shepherd. As I understand and recall, the changes can be summed up as:

- Added an author.
- Many SHOULD changed to MUST, as a result of document shepherd feedback.
- New section 3.2.7 on IP-in-IP.
- Change to section 6.1 (was "No Impact on BGP Decision Process” changed to "Impact on BGP Decision Process”) as a result of implementation feedback.
- Change to section 8.1, regarding implicit VRFs in some contexts.

Authors, if I’ve missed or misrepresented anything, please follow up.

Since some of the changes are normative I think we should give the WG a chance to review and comment. Please provide any comments by Friday, June 7. Please try to restrict your comments to substantive changes subsequent to WGLC.

Thanks,

—John


On May 21, 2019, at 12:00 AM, [e-mail]<mailto:[e-mail]> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

    Title           : The BGP Tunnel Encapsulation Attribute
    Authors         : Keyur Patel
                      Gunter Van de Velde
                      Srihari R. Sangli
                      Eric C. Rosen
Filename        : draft-ietf-idr-tunnel-encaps-12.txt
Pages           : 42
Date            : 2019-05-20
...
_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Fmailman-252Flistinfo-252Fidr-26amp-3Bdata-3D02-257C01-257Cldunbar-2540futurewei.com-257C9af237ec86d44ee6546d08d6eb5cef27-257C0fee8ff2a3b240189c753a1d5591fedc-257C1-257C0-257C636955181720991287-26amp-3Bsdata-3DzW-252FkQhtk92bdpruE3cSQQN8wO9c-252Bpornx64zw5ATb4Y-253D-26amp-3Breserved-3D0-3D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=zlNlU1fIrzLHsR8ptaoICogwrs4z3YR3MSw_Pr3BY-s&s=IE81TiSbDlbeHWx3L8aguXJCK3nQFT3LXtvnryyoYtk&e=<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Fmailman-252Flistinfo-252Fidr-26amp-3Bdata-3D02-257C01-257Cldunbar-2540futurewei.com-257C9af237ec86d44ee6546d08d6eb5cef27-257C0fee8ff2a3b240189c753a1d5591fedc-257C1-257C0-257C636955181720991287-26amp-3Bsdata-3DzW-252FkQhtk92bdpruE3cSQQN8wO9c-252Bpornx64zw5ATb4Y-253D-26amp-3Breserved-3D0-3D%26d%3DDwIGaQ%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DhLt5iDJpw7ukqICc0hoT7A%26m%3DzlNlU1fIrzLHsR8ptaoICogwrs4z3YR3MSw_Pr3BY-s%26s%3DIE81TiSbDlbeHWx3L8aguXJCK3nQFT3LXtvnryyoYtk%26e%3D&data=02%7C01%7Cldunbar%40futurewei.com%7C5b5c33ebdca54485945408d6eb5fba66%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636955193727084624&sdata=4uiGWo4F5TQV2IPGckm39dKZZR8imoNsITEUIkhiYCQ%3D&reserved=0>

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Fmailman-252Flistinfo-252Fidr-26amp-3Bdata-3D02-257C01-257Cldunbar-2540futurewei.com-257C9af237ec86d44ee6546d08d6eb5cef27-257C0fee8ff2a3b240189c753a1d5591fedc-257C1-257C0-257C636955181720991287-26amp-3Bsdata-3DzW-252FkQhtk92bdpruE3cSQQN8wO9c-252Bpornx64zw5ATb4Y-253D-26amp-3Breserved-3D0-3D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=zlNlU1fIrzLHsR8ptaoICogwrs4z3YR3MSw_Pr3BY-s&s=IE81TiSbDlbeHWx3L8aguXJCK3nQFT3LXtvnryyoYtk&e=<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Fmailman-252Flistinfo-252Fidr-26amp-3Bdata-3D02-257C01-257Cldunbar-2540futurewei.com-257C9af237ec86d44ee6546d08d6eb5cef27-257C0fee8ff2a3b240189c753a1d5591fedc-257C1-257C0-257C636955181720991287-26amp-3Bsdata-3DzW-252FkQhtk92bdpruE3cSQQN8wO9c-252Bpornx64zw5ATb4Y-253D-26amp-3Breserved-3D0-3D%26d%3DDwIGaQ%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DhLt5iDJpw7ukqICc0hoT7A%26m%3DzlNlU1fIrzLHsR8ptaoICogwrs4z3YR3MSw_Pr3BY-s%26s%3DIE81TiSbDlbeHWx3L8aguXJCK3nQFT3LXtvnryyoYtk%26e%3D&data=02%7C01%7Cldunbar%40futurewei.com%7C5b5c33ebdca54485945408d6eb5fba66%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636955193727084624&sdata=4uiGWo4F5TQV2IPGckm39dKZZR8imoNsITEUIkhiYCQ%3D&reserved=0>

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Fmailman-252Flistinfo-252Fidr-26amp-3Bdata-3D02-257C01-257Cldunbar-2540futurewei.com-257C9af237ec86d44ee6546d08d6eb5cef27-257C0fee8ff2a3b240189c753a1d5591fedc-257C1-257C0-257C636955181720991287-26amp-3Bsdata-3DzW-252FkQhtk92bdpruE3cSQQN8wO9c-252Bpornx64zw5ATb4Y-253D-26amp-3Breserved-3D0&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=zlNlU1fIrzLHsR8ptaoICogwrs4z3YR3MSw_Pr3BY-s&s=twAWkDtth66RpaHegq76M2VhDoxlOOdXxDOnG6d8umk&e=<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Fmailman-252Flistinfo-252Fidr-26amp-3Bdata-3D02-257C01-257Cldunbar-2540futurewei.com-257C9af237ec86d44ee6546d08d6eb5cef27-257C0fee8ff2a3b240189c753a1d5591fedc-257C1-257C0-257C636955181720991287-26amp-3Bsdata-3DzW-252FkQhtk92bdpruE3cSQQN8wO9c-252Bpornx64zw5ATb4Y-253D-26amp-3Breserved-3D0%26d%3DDwIGaQ%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DhLt5iDJpw7ukqICc0hoT7A%26m%3DzlNlU1fIrzLHsR8ptaoICogwrs4z3YR3MSw_Pr3BY-s%26s%3DtwAWkDtth66RpaHegq76M2VhDoxlOOdXxDOnG6d8umk%26e%3D&data=02%7C01%7Cldunbar%40futurewei.com%7C5b5c33ebdca54485945408d6eb5fba66%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636955193727094618&sdata=777ehC3j5OZMh2JPV0X6Zhx4%2FQbeNup57kEz1NotooA%3D&reserved=0>