Re: [Status] Summary of STATUS BOF and the next steps

[<[e-mail]>]

Hannes,

In case, we are using only directed forwarding (adjacency segment), could we still talk about tunneling ? (it's a very very small tunnel)
Moreover talking about "stacking" is really dataplane agnostic (MPLS) ...

In the proposed segment routing architectural concepts, segments are at the same "level" and pointer moves on the segment list, then the MPLS instantiation is performing this using stacking ...

IMHO, if we use "Stacked Tunnels", we already talk about a chosen solution and it's closing the door to something else  ...

Finally, about the "routing" word, routing is essentially a "forward" action which may limit the scope of what we can do by using a segment list. Actions associated with a segment could be something else than forwarding.

Do we want in the charter to limit the scope to routing actions ?

I have no solution today to propose for the naming, but I completely agree with Loa, to first focus on working on the charter, and define a clear scope of the work and then the name will be easier to find.

Regarding your charter proposal :

--------

- They form a connected network
        [SLI] InterAS case must be included, but the WG can go step by step and first release intraAS, and then doing interAS (in relation with IDR ??).

- They can forward traffic through the shortest paths or paths other than the shortest (the latter called explicitly routed paths, or explicit paths)
        [SLI] There is something else between SPT and Explicit path, you can define other algorithms than SPT to define a path, and it's not explicit path. Moreover I come back to my comment, on do we want to limit the scope to routing ? I would say no.

- They share a common trust model. In this model, any router within the ERD can specify an explicit path between itself and any other router in the ERD. It can then send any packet that passes through it through any path that it has specified.
        [SLI] Security considerations may have to be addressed in the charter , especially for the interAS case (trust yes, but not sure access to everything may not be good)

Downstream routers within the ERD forward the packet as specified by the router at the head-end of the path.
[SLI] Yes, but any router in the middle may be able to change the end to end explicit path.



- The first goal of the STER WG is to identify use-cases for ERDs.
- Having identified use-cases, the WG will identify gaps between currently available technologies and use-case requirements.
- The WG will then define requirements for extensions to existing protocols or new protocols that address gaps that are identified.

[SLI] Agree, I would add :
- defining the architecture framework
- analysing the security considerisations


---------


Here would be my proposal to extend yours :

A <named to be defined> domain contains a set of routers with the following characteristics:

- They form a connected network
- They can forward traffic through any path within the network using shortest path, non shortest path or explicit path
- They may provide other types of services than forwarding and they can enforce service actions in the path.
- They share a common trust model. In this model, any router within the domain can specify a path between itself and any other router in the domain. It may then send any packet that passes through it through any path that it has specified and that is conform to the security rules. Downstream routers within the ERD forward the packet as specified by the router at the head-end of the path.

The <name> working group is chartered for the following ordered list of work items:

- The first goal of the WG is to identify use-cases.
- The WG will then define the architecture framework associated with the security considerations. The architecture framework and security considerations must address the relations between domains (interdomain).
- Having identified use-cases, architecture and security, the WG will identify gaps between currently available technologies and use-case requirements.
- The WG will then define requirements for extensions to existing protocols or new protocols that address gaps that are identified.
- The WG will first focus on the intra-domain forwarding definition.

Protocol work may be carried out in this working group or in other working groups responsible for the protocols, in coordination with this WG, and in agreement with the WG chairs and responsible ADs. However, no protocol work will be adopted by a working group to address the ERD use-cases until the requirements document motivating the protocol work has been sent to the IESG for publication as an RFC.

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de Hannes Gredler
Envoyé : mardi 3 septembre 2013 18:31
À : Loa Andersson
Cc : [e-mail]
Objet : Re: [Status] Summary of STATUS BOF and the next steps

good point - what about this charter proposal ?

---

Stacked Tunnels for Explicit Routing (STER) ===========================================

A explicit routing domain (ERD) contains a set of routers with the following characteristics:

- They form a connected network
- They can forward traffic through the shortest paths or paths other than the shortest (the latter called explicitly routed paths, or explicit paths)
- They share a common trust model. In this model, any router within the ERD can specify an explicit path between itself and any other router in the ERD. It can then send any packet that passes through it through any path that it has specified. Downstream routers within the ERD forward the packet as specified by the router at the head-end of the path.

The STER working group is chartered for the following ordered list of work items:

- The first goal of the STER WG is to identify use-cases for ERDs.
- Having identified use-cases, the WG will identify gaps between currently available technologies and use-case requirements.
- The WG will then define requirements for extensions to existing protocols or new protocols that address gaps that are identified.

Protocol work may be carried out in this working group or in other working groups responsible for the protocols, in coordination with this WG, and in agreement with the WG chairs and responsible ADs. However, no protocol work will be adopted by a working group to address the ERD use-cases until the requirements document motivating the protocol work has been sent to the IESG for publication as an RFC.

---

<flame suit on>

/hannes


On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:

> Folks,
>
> Excuse me if I'm slightly out of the loop, but so far I have not seen
> a charter proposal, if there is one please point me to it.
>
> It seems a bit odd to put the cart (what the wg should do) before the
> horse (wg name). If we drill down the the charter first the wg name
> might be easier to figure out.
>
> /Loa
>
> PS
> OK I understand that the horse and cart analogy limps a  bit :).
>
>
>
> On 2013-09-03 17:22, AshwoodsmithPeter wrote:
>> " If the WG charter is limited to source routing, how will we handle the "non source routing" use cases of segment routing ? In another working group ? So we will go back to the WG synchronization issue that has been raised for this technology ..."
>>
>> That's why I suggested SRV2. We are revisiting source routing with new concepts. More generic number/action behavior.
>>
>> Peter
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of [e-mail]
>> Sent: Tuesday, September 03, 2013 10:43 AM
>> To: AshwoodsmithPeter
>> Cc: [e-mail]
>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>
>>
>> There was a misunderstanding in my small comment :) so I will explain more :
>>
>> In segment routing, you have more than basic source routing : segment routing is just associate a segment number to an action and then combine segment as you want, yes you can do source routing, but you also can do more.
>>
>> In the other hand, I completely agree with your statement that source
>> routing is generic and dataplane agnostic, as segment routing is ...
>> (segment routing is not a new dataplane ...)
>>
>> Now the definition of the WG naming must be inline with the charter
>> that will be defined ... (draft today)
>>
>> Based on the already existing consensus (at least for MPLS dataplane) brought up during Berlin STATUS BOF meeting, segment routing sounds to be a good target candidate.
>>
>> So now, do we want to do more in the WG charter than just make progressing segment routing architecture and uses cases document and ensure coordination for the standardization of this technology ?
>>
>> Do we want to standardize other technologies in this WG ? I don't think so, based on Stewart's conclusion email from the BOF :"A new WG focused solely on SR therefore needs to be create"
>>
>> If the WG charter is limited to source routing, how will we handle the "non source routing" use cases of segment routing ? In another working group ? So we will go back to the WG synchronization issue that has been raised for this technology ...
>>
>> If the WG is focused on SR, let's use a name in relation with SR.
>>
>> Feedback ?
>>
>>
>> Stephane
>>
>>
>> -----Message d'origine-----
>> De : AshwoodsmithPeter [mailto:[e-mail]]
>> Envoyé : mardi 3 septembre 2013 15:27 À : LITKOWSKI Stephane DTF/DERX
>> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione
>> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana);
>> [e-mail]; Stewart Bryant (stbryant) Objet : Re: [Status]
>> Summary of STATUS BOF and the next steps
>>
>> The term "source routing" has been around for a very long time and is data path agnostic. Its also the term used in the literature etc so my preference is to stick with this existing well known and data path agnostic term.
>>
>> Peter
>>
>> On Sep 3, 2013, at 9:07 AM, "[e-mail]" <[e-mail]> wrote:
>>
>>> Hi,
>>>
>>> "Source routing" is just a subcase of segment routing ... as it is for IP routing ...
>>>
>>> Stephane
>>>
>>>
>>> -----Message d'origine-----
>>> De : [e-mail] [mailto:[e-mail]] De la
>>> part de John E Drake Envoyé : mardi 3 septembre 2013 15:02 À : Mark
>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; [e-mail];
>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF
>>> and the next steps
>>>
>>> Hi,
>>>
>>> What is this 'segment routing' silliness?  The correct term is 'source routing'.
>>>
>>> Yours Irrespectively,
>>>
>>> John
>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On
>>>> Behalf Of Mark Townsley
>>>> Sent: Sunday, September 01, 2013 10:08 AM
>>>> To: Victor Kuarsingh
>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>> Alvaro Retana (aretana); [e-mail]; Stewart Bryant (stbryant)
>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps
>>>>
>>>>
>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote:
>>>>
>>>>> All,
>>>>>
>>>>> I would also favour "Segment Routing WG" as well.
>>>>>
>>>>> I note this since attempting to come up with an all encompassing
>>>>> acronym will be difficult and Segment Routing is generic enough to
>>>>> associate to multiple functions.
>>>>
>>>> Then we can just use "segroute" for the short name. WGs do not have
>>>> to have acronyms, but they do need to have an 8-char limited short
>>>> name for the various automated tools not to break.
>>>>
>>>> - Mark
>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Victor K
>>>>>
>>>>>
>>>>>
>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"
>>>>> <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> +1 for Segment Routing WG
>>>>>>
>>>>>> Roberta
>>>>>>
>>>>>> Sent from my iPad
>>>>>>
>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)"
>>>>>> <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>> Segment Routing WG
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>>>>>>> <[e-mail]> wrote:
>>>>>>>
>>>>>>>> The second task, which hopefully should be relatively easy, is
>>>>>>>> to find a better working name for the WG, since it has been put
>>>>>>>> to me a number of times that STATUS is going to be confusing in
>>>>>>>> text and a difficult search term.
>>>>>>> _______________________________________________
>>>>>>> status mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>> _______________________________________________
>>>>>> status mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>
>>>> _______________________________________________
>>>> status mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>>
>>> _______________________________________________
>>> status mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>> ____________________________________________________________________
>>> __ ___________________________________________________
>>>
>>> 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.
>>>
>>> _______________________________________________
>>> status mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/status
>>
>> _____________________________________________________________________
>> ____________________________________________________
>>
>> 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.
>>
>> _______________________________________________
>> status mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/status
>> _______________________________________________
>> status mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/status
>>
>
> --
>
>
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Huawei Technologies (consultant)     phone: [phone]
> _______________________________________________
> status mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/status
>
>


_______________________________________________
status mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/status

_________________________________________________________________________________________________________________________

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.