Subject: [Roll] Latest version of useofrplinfo-36

From: Ines Robles <[email-masked]>
Date: Tue, 3 Mar 2020 16:55:24 +0200

Dear all,

useofrplinfo draft was updated (version 36) from the last call considering:

- Advertising External Routes with Non- Storing Mode Signaling (section 4.1)

Then, for SM cases where the communication flow starts at RUL: it goes
encapsulated to the root. (Figure 7 updated and the cases updated: RUL to
root/RUL to Int/ RUL to RAL/ RUL to RUL)

For Non-SM cases (Figure 14):

1- From RAL to Int: It may have encapsulation to the root.
2- From RAL to RAL and RAL To RUL : It may have encapsulation to the root
and must have encapsulation to the destination
3- From RUL to RAL and RUL to RUL: It must hae encapsulation to the root
and to the destination (RAL) or to the 6LR parent of RUL.

Thus, new tables were added considering the "may" cases. e.g Section 8.3.1.
We added new terminology as well.

Comments welcome and thank you,

The authors.

---

From: <[email-masked]>
Date: Fri, 6 Mar 2020 09:36:25 +0000

Hello Working Group,

draft-ietf-roll-useofrplinfo has recently been updated to revision –36.
As a reminder, revision –31 was approved by the IESG in July, the RFC Editor worked on it, then the document was pulled back from the RFC Editor.
We believe that the Working Group has been well informed of the changes made to the document since then, and these changes have been discussed on the mailing list and at IETF106.
We are therefore not going to issue another Last Call within the Working Group.

However, if you have an interest in this draft and have not paid attention to the changes over the last months, here is your last chance: you can review the changes between –31 and –36 https://www.ietf.org/rfcdiff?url1=draft-ietf-roll-useofrplinfo-31&url2=draft-ietf-roll-useofrplinfo-36 and let us know of significant concerns by Monday noon CET, in time for draft publication cutoff before IET107.

Thanks and best regards,

Dominique

De : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date : Tuesday 3 March 2020 15:55
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc : Dominique Barthel <[email-masked]<mailto:[email-masked]>>, "Michael ca>" <[email-masked]<mailto:[email-masked]>>, Pascal Thubert <[email-masked]<mailto:[email-masked]>>
Objet : Latest version of useofrplinfo-36

Dear all,

Then, for SM cases where the communication flow starts at RUL: it goes encapsulated to the root. (Figure 7 updated and the cases updated: RUL to root/RUL to Int/ RUL to RAL/ RUL to RUL)

1- From RAL to Int: It may have encapsulation to the root.
2- From RAL to RAL and RAL To RUL : It may have encapsulation to the root and must have encapsulation to the destination
3- From RUL to RAL and RUL to RUL: It must hae encapsulation to the root and to the destination (RAL) or to the 6LR parent of RUL.

Thus, new tables were added considering the "may" cases. e.g Section 8.3.1. We added new terminology as well.

The authors.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.