NSI endpoint references
Hi folks- We need to still decide on an NSI endpoint reference scheme. This is essentially a means to uniquely identify end points within the *NSI* context. I think it is very important that we not confuse the "NSI endpoint reference" with the topology information that the NSAs may internally associate with an end point, or that other non-NSI functions may require. The NSI topology model only specifies "networks" and "edge/end points". And where an end endpoint in one network coincides with an end point in another network, NSI topology captures this peering connection relationship too. But this is /_all_/ NSI has regarding topology(!) This is the NSI "context". As far as I can see, all we really need within the NSI-CS specification is a "network identifier" : "endpoint identifier" tuple to uniquely identify an NSI-CS termination point. These NSI references are only relevant within the NSI context. I.e. Any mapping of NSI endpoint references to NRM resources is NRM specific and therefore (IMO) out of scope for the NSI standard (i.e. put another way: it is the NRM's responsibility to perform that mapping.) Further, I believe such mapping is only a local issue, so we should not promote other information beyond that local scope by allowing (or requiring) other information in the NSI endpoint reference itself. We should keep the NSI endpoint reference abstracted above any specific local or physical information. If physical topological information is important to the NSI, then we have a much bigger problem. And if an NSA requires such information, it should ask the owner/leaf NSA who presumably knows how to get that information from the NRM. The attached GLIF Global ID recommendation provides a good coverage of names in this respect. It defines a global identifier thusly: <GID> := <domain part> ":" <local part>. I think this is close to what JohnM was referring to on the call this week(?) Since this does provide the two basic components that NSI requires, (a "network" name and a "local part" for endpoint name) I think this will be a good and minimally sufficient way to specify NSI-CS termination points in version 1.0. The GLIF recommendation also allows for URN extensions. However, I would not include these as part of the NSI specification unless a) it maintains the network::endpoint tuple of NSI, and b) we can specify exactly what that URN should be and why it is necessary for NSI to function properly. At this time, I believe a simple name like "nordu.net:CPH-AMS-10GE" or "NetherLight:pSonar" is sufficient for v1.0. i.e. references without a urn: prefix. If someone thinks we need a URN specification for version 1.0, please pipe up and provide the reasoning - there may be such, I just am unaware of one in my mind at this moment. (But please don't tell me its needed for web services-WS is not why we created NSI:-). Adding a URN prefix qualifies the namespace - why does/should NSI need a qualified namespace for endpoint references? If you think we do, or even if you think it is just a good idea, please explain how this reconciles with the NSI architecture - i.e. how the URN version maps the <network><endpoint> tuple, and how it improves the basic GID mentioned above? Remember, we are only speaking to _/NSI/_ endpoint references,... I think as long as the basic <domain name><local part> tuple is maintained in an endpoint reference (in conformance with the NSI architecture), and the syntactic parsing is clear, then we do actually have a good bit of flexibility in the strings themselves. Thoughts? Jerry PS: With respect to how the NSI to NRM mapping takes place for each respective NRM, I think this should be described in the NRM implementation guide, not the NSI specification. NSI is NRM agnostic. While this does imply some translation function is required at the NSA, it keeps naming consistent across the entire NSI universe. (And I assert that the mapping is only meaningful locally anyway.)
Jerry, If I may distill your email to: "Let's define an NSI-CS endpoint reference as this tuple: (globally unique domain identifier, locally scoped opaque identifier)." I'm fine with that definition. The actual implementation/representation/format of such a tuple should be left to the implementors of the protocol. It's just an ordered pair of strings, it does not deserve a big discussion about formats. On Mar 10, 2011, at 8:16 AM, Jerry Sobieski wrote:
Hi folks-
We need to still decide on an NSI endpoint reference scheme. This is essentially a means to uniquely identify end points within the *NSI* context.
I think it is very important that we not confuse the "NSI endpoint reference" with the topology information that the NSAs may internally associate with an end point, or that other non-NSI functions may require. The NSI topology model only specifies "networks" and "edge/end points". And where an end endpoint in one network coincides with an end point in another network, NSI topology captures this peering connection relationship too. But this is all NSI has regarding topology(!) This is the NSI "context".
As far as I can see, all we really need within the NSI-CS specification is a "network identifier" : "endpoint identifier" tuple to uniquely identify an NSI-CS termination point. These NSI references are only relevant within the NSI context. I.e. Any mapping of NSI endpoint references to NRM resources is NRM specific and therefore (IMO) out of scope for the NSI standard (i.e. put another way: it is the NRM's responsibility to perform that mapping.) Further, I believe such mapping is only a local issue, so we should not promote other information beyond that local scope by allowing (or requiring) other information in the NSI endpoint reference itself. We should keep the NSI endpoint reference abstracted above any specific local or physical information. If physical topological information is important to the NSI, then we have a much bigger problem. And if an NSA requires such information, it should ask the owner/leaf NSA who presumably knows how to get that information from the NRM.
The attached GLIF Global ID recommendation provides a good coverage of names in this respect. It defines a global identifier thusly: <GID> := <domain part> ":" <local part>. I think this is close to what JohnM was referring to on the call this week(?) Since this does provide the two basic components that NSI requires, (a "network" name and a "local part" for endpoint name) I think this will be a good and minimally sufficient way to specify NSI-CS termination points in version 1.0.
The GLIF recommendation also allows for URN extensions. However, I would not include these as part of the NSI specification unless a) it maintains the network::endpoint tuple of NSI, and b) we can specify exactly what that URN should be and why it is necessary for NSI to function properly. At this time, I believe a simple name like "nordu.net:CPH-AMS-10GE" or "NetherLight:pSonar" is sufficient for v1.0. i.e. references without a urn: prefix.
If someone thinks we need a URN specification for version 1.0, please pipe up and provide the reasoning - there may be such, I just am unaware of one in my mind at this moment. (But please don't tell me its needed for web services-WS is not why we created NSI:-). Adding a URN prefix qualifies the namespace - why does/should NSI need a qualified namespace for endpoint references? If you think we do, or even if you think it is just a good idea, please explain how this reconciles with the NSI architecture - i.e. how the URN version maps the <network><endpoint> tuple, and how it improves the basic GID mentioned above? Remember, we are only speaking to NSI endpoint references,...
I think as long as the basic <domain name><local part> tuple is maintained in an endpoint reference (in conformance with the NSI architecture), and the syntactic parsing is clear, then we do actually have a good bit of flexibility in the strings themselves.
Thoughts? Jerry
PS: With respect to how the NSI to NRM mapping takes place for each respective NRM, I think this should be described in the NRM implementation guide, not the NSI specification. NSI is NRM agnostic. While this does imply some translation function is required at the NSA, it keeps naming consistent across the entire NSI universe. (And I assert that the mapping is only meaningful locally anyway.)
<GLIF Naming Conventions for GID.pdf>_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- Evangelos Chaniotakis Network Engineer, ESnet Visit our blog: http://bit.ly/9mNapV
Hi Vangelis- You are right except for one part:... As I see this, it is really only the NRM that cares about the endpoint name. NSI has no interest in what the endpoint string looks like other than maybe some purely aesthetic lexical conventions (e.g. no backspace characters, etc.) Therefore, the *NSI* protocol implementers must explicitly treat the string as just a string. If one domain wants to name its endpoints with topology info encoded, they can do that, but no other domain or NSA will look for that info in their string...as far as the other NSAs are concerned, the string is just a string. I will say though that for the mapping of the NSI endpoint reference to the NRM resource *is* the responsibility of the implementors who are coding the PA frontend onto an NRM. They do need to know if local convention expects or requires local endpoints to be named a certain way. But again it is only relevant for the local endpoints, and so is only of local significance and only for that particular NRM. So this is not an NSI issue. I recommend that we are explicit in the NSI standard and say the following: The <local part> of the endpoint reference is a string that uniquely identifies a particular endpoint within the <domain> specified. The NSI framework and protocol explicitly leave the value of the endpoint reference string to be assigned by the network domain within which the endpoint resides. The NSI Framework and protocol do not encode any information directly into the endpoint reference string. How is that? This insures that local domains have full sway to name their own endpoints as they see fit. Best regards Jerry On 3/10/11 11:48 AM, Evangelos Chaniotakis wrote:
Jerry,
If I may distill your email to:
"Let's define an NSI-CS endpoint reference as this tuple: (globally unique domain identifier, locally scoped opaque identifier)."
I'm fine with that definition.
The actual implementation/representation/format of such a tuple should be left to the implementors of the protocol. It's just an ordered pair of strings, it does not deserve a big discussion about formats.
On Mar 10, 2011, at 8:16 AM, Jerry Sobieski wrote:
Hi folks-
We need to still decide on an NSI endpoint reference scheme. This is essentially a means to uniquely identify end points within the *NSI* context.
I think it is very important that we not confuse the "NSI endpoint reference" with the topology information that the NSAs may internally associate with an end point, or that other non-NSI functions may require. The NSI topology model only specifies "networks" and "edge/end points". And where an end endpoint in one network coincides with an end point in another network, NSI topology captures this peering connection relationship too. But this is all NSI has regarding topology(!) This is the NSI "context".
As far as I can see, all we really need within the NSI-CS specification is a "network identifier" : "endpoint identifier" tuple to uniquely identify an NSI-CS termination point. These NSI references are only relevant within the NSI context. I.e. Any mapping of NSI endpoint references to NRM resources is NRM specific and therefore (IMO) out of scope for the NSI standard (i.e. put another way: it is the NRM's responsibility to perform that mapping.) Further, I believe such mapping is only a local issue, so we should not promote other information beyond that local scope by allowing (or requiring) other information in the NSI endpoint reference itself. We should keep the NSI endpoint reference abstracted above any specific local or physical information. If physical topological information is important to the NSI, then we have a much bigger problem. And if an NSA requires such information, it should ask the owner/leaf NSA who presumably knows how to get that information from the NRM.
The attached GLIF Global ID recommendation provides a good coverage of names in this respect. It defines a global identifier thusly: <GID> := <domain part> ":" <local part>. I think this is close to what JohnM was referring to on the call this week(?) Since this does provide the two basic components that NSI requires, (a "network" name and a "local part" for endpoint name) I think this will be a good and minimally sufficient way to specify NSI-CS termination points in version 1.0.
The GLIF recommendation also allows for URN extensions. However, I would not include these as part of the NSI specification unless a) it maintains the network::endpoint tuple of NSI, and b) we can specify exactly what that URN should be and why it is necessary for NSI to function properly. At this time, I believe a simple name like "nordu.net:CPH-AMS-10GE" or "NetherLight:pSonar" is sufficient for v1.0. i.e. references without a urn: prefix.
If someone thinks we need a URN specification for version 1.0, please pipe up and provide the reasoning - there may be such, I just am unaware of one in my mind at this moment. (But please don't tell me its needed for web services-WS is not why we created NSI:-). Adding a URN prefix qualifies the namespace - why does/should NSI need a qualified namespace for endpoint references? If you think we do, or even if you think it is just a good idea, please explain how this reconciles with the NSI architecture - i.e. how the URN version maps the <network><endpoint> tuple, and how it improves the basic GID mentioned above? Remember, we are only speaking to NSI endpoint references,...
I think as long as the basic <domain name><local part> tuple is maintained in an endpoint reference (in conformance with the NSI architecture), and the syntactic parsing is clear, then we do actually have a good bit of flexibility in the strings themselves.
Thoughts? Jerry
PS: With respect to how the NSI to NRM mapping takes place for each respective NRM, I think this should be described in the NRM implementation guide, not the NSI specification. NSI is NRM agnostic. While this does imply some translation function is required at the NSA, it keeps naming consistent across the entire NSI universe. (And I assert that the mapping is only meaningful locally anyway.)
<GLIF Naming Conventions for GID.pdf>_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Jerry, I disagree with part of what you're saying here: i.e. that the entire endpoint reference is a string. In my opinion the standard should define it is an abstract tuple: (domain-id, local-id). The implementation of the standard should decide how to encode that tuple. It could be a pair of two XML elements for SOAP, or a colon- delimited concatenation, or whatever. It's absolutely trivial to go the extra mile and support multiple representations, converting between them on the fly. Let me propose this schema snippet for the SOAP implementation: <xsd:complexType name="nsiEndpointReference"> <xsd:sequence> <xsd:element name="domainId" type="xsd:string" maxOccurs="1" minOccurs="1"/> <xsd:element name="localId" type="xsd:string" maxOccurs="1" minOccurs="1"/> </xsd:sequence> </xsd:complexType> I do agree with the points you're making about the local part, and I'm fine with the clarification you want to explicitly set in the standard. In my opinion a much more important clarification needs to be made about the domain-id part. Here are some questions that should probably be answered. - Does a domain-id represent ownership/responsibility of the EPR by an NSA? - Can an EPR "belong to" multiple NSAs? - Does this affect which NSAs receive a connection request? If so, how? On Mar 10, 2011, at 12:03 PM, Jerry Sobieski wrote:
Hi Vangelis-
You are right except for one part:... As I see this, it is really only the NRM that cares about the endpoint name. NSI has no interest in what the endpoint string looks like other than maybe some purely aesthetic lexical conventions (e.g. no backspace characters, etc.) Therefore, the *NSI* protocol implementers must explicitly treat the string as just a string. If one domain wants to name its endpoints with topology info encoded, they can do that, but no other domain or NSA will look for that info in their string...as far as the other NSAs are concerned, the string is just a string.
I will say though that for the mapping of the NSI endpoint reference to the NRM resource *is* the responsibility of the implementors who are coding the PA frontend onto an NRM. They do need to know if local convention expects or requires local endpoints to be named a certain way. But again it is only relevant for the local endpoints, and so is only of local significance and only for that particular NRM. So this is not an NSI issue.
I recommend that we are explicit in the NSI standard and say the following: The <local part> of the endpoint reference is a string that uniquely identifies a particular endpoint within the <domain> specified. The NSI framework and protocol explicitly leave the value of the endpoint reference string to be assigned by the network domain within which the endpoint resides. The NSI Framework and protocol do not encode any information directly into the endpoint reference string.
How is that? This insures that local domains have full sway to name their own endpoints as they see fit.
Best regards Jerry
On 3/10/11 11:48 AM, Evangelos Chaniotakis wrote:
Jerry,
If I may distill your email to:
"Let's define an NSI-CS endpoint reference as this tuple: (globally unique domain identifier, locally scoped opaque identifier)."
I'm fine with that definition.
The actual implementation/representation/format of such a tuple should be left to the implementors of the protocol. It's just an ordered pair of strings, it does not deserve a big discussion about formats.
-- Evangelos Chaniotakis Network Engineer, ESnet Visit our blog: http://bit.ly/9mNapV
Oops, forgot to make both components mandatory as Vangelis has. I guess I should have moved back in time :-) Are we defining an STP or an endpoint? Are they the same and we are just changing terminology? I am a bit confused.
- Does a domain-id represent ownership/responsibility of the EPR by an NSA? - Can an EPR "belong to" multiple NSAs?
I think we are saying an endpoint belongs to a single domain, but I believe multiple NSA could manage the same domain, and therefore, the same endpoint.
- Does this affect which NSAs receive a connection request? If so, how?
Domain to NSA resolution is out of scope based on the last NSI call. John. On 2011-03-10, at 4:19 PM, Evangelos Chaniotakis wrote:
Jerry,
I disagree with part of what you're saying here: i.e. that the entire endpoint reference is a string. In my opinion the standard should define it is an abstract tuple: (domain-id, local-id).
The implementation of the standard should decide how to encode that tuple. It could be a pair of two XML elements for SOAP, or a colon- delimited concatenation, or whatever. It's absolutely trivial to go the extra mile and support multiple representations, converting between them on the fly.
Let me propose this schema snippet for the SOAP implementation:
<xsd:complexType name="nsiEndpointReference"> <xsd:sequence> <xsd:element name="domainId" type="xsd:string" maxOccurs="1" minOccurs="1"/> <xsd:element name="localId" type="xsd:string" maxOccurs="1" minOccurs="1"/> </xsd:sequence> </xsd:complexType>
I do agree with the points you're making about the local part, and I'm fine with the clarification you want to explicitly set in the standard.
In my opinion a much more important clarification needs to be made about the domain-id part. Here are some questions that should probably be answered.
- Does a domain-id represent ownership/responsibility of the EPR by an NSA? - Can an EPR "belong to" multiple NSAs? - Does this affect which NSAs receive a connection request? If so, how?
On Mar 10, 2011, at 12:03 PM, Jerry Sobieski wrote:
Hi Vangelis-
You are right except for one part:... As I see this, it is really only the NRM that cares about the endpoint name. NSI has no interest in what the endpoint string looks like other than maybe some purely aesthetic lexical conventions (e.g. no backspace characters, etc.) Therefore, the *NSI* protocol implementers must explicitly treat the string as just a string. If one domain wants to name its endpoints with topology info encoded, they can do that, but no other domain or NSA will look for that info in their string...as far as the other NSAs are concerned, the string is just a string.
I will say though that for the mapping of the NSI endpoint reference to the NRM resource *is* the responsibility of the implementors who are coding the PA frontend onto an NRM. They do need to know if local convention expects or requires local endpoints to be named a certain way. But again it is only relevant for the local endpoints, and so is only of local significance and only for that particular NRM. So this is not an NSI issue.
I recommend that we are explicit in the NSI standard and say the following: The <local part> of the endpoint reference is a string that uniquely identifies a particular endpoint within the <domain> specified. The NSI framework and protocol explicitly leave the value of the endpoint reference string to be assigned by the network domain within which the endpoint resides. The NSI Framework and protocol do not encode any information directly into the endpoint reference string.
How is that? This insures that local domains have full sway to name their own endpoints as they see fit.
Best regards Jerry
On 3/10/11 11:48 AM, Evangelos Chaniotakis wrote:
Jerry,
If I may distill your email to:
"Let's define an NSI-CS endpoint reference as this tuple: (globally unique domain identifier, locally scoped opaque identifier)."
I'm fine with that definition.
The actual implementation/representation/format of such a tuple should be left to the implementors of the protocol. It's just an ordered pair of strings, it does not deserve a big discussion about formats.
-- Evangelos Chaniotakis Network Engineer, ESnet Visit our blog: http://bit.ly/9mNapV
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Yes I think there might be some "crosstalk" here. I think Jerry is talking about STPs and Vangelis may be talking about NSA EPR? Regarding STPs, since there is amapping of STP to a data plane topological space, whether multiple NSA's advertise same end-point is upto the implementation of the domain and its policy. We had agreed a while ago that ONE NRM "owns" the provisioning and resource allocation of that end-point. btw, someone keeping track of how many things are out of scope of NSI? :) Inder On Mar 12, 2011, at 5:49 PM, John MacAuley wrote:
Oops, forgot to make both components mandatory as Vangelis has. I guess I should have moved back in time :-)
Are we defining an STP or an endpoint? Are they the same and we are just changing terminology? I am a bit confused.
- Does a domain-id represent ownership/responsibility of the EPR by an NSA? - Can an EPR "belong to" multiple NSAs?
I think we are saying an endpoint belongs to a single domain, but I believe multiple NSA could manage the same domain, and therefore, the same endpoint.
- Does this affect which NSAs receive a connection request? If so, how?
Domain to NSA resolution is out of scope based on the last NSI call.
John.
On 2011-03-10, at 4:19 PM, Evangelos Chaniotakis wrote:
Jerry,
I disagree with part of what you're saying here: i.e. that the entire endpoint reference is a string. In my opinion the standard should define it is an abstract tuple: (domain-id, local-id).
The implementation of the standard should decide how to encode that tuple. It could be a pair of two XML elements for SOAP, or a colon- delimited concatenation, or whatever. It's absolutely trivial to go the extra mile and support multiple representations, converting between them on the fly.
Let me propose this schema snippet for the SOAP implementation:
<xsd:complexType name="nsiEndpointReference"> <xsd:sequence> <xsd:element name="domainId" type="xsd:string" maxOccurs="1" minOccurs="1"/> <xsd:element name="localId" type="xsd:string" maxOccurs="1" minOccurs="1"/> </xsd:sequence> </xsd:complexType>
I do agree with the points you're making about the local part, and I'm fine with the clarification you want to explicitly set in the standard.
In my opinion a much more important clarification needs to be made about the domain-id part. Here are some questions that should probably be answered.
- Does a domain-id represent ownership/responsibility of the EPR by an NSA? - Can an EPR "belong to" multiple NSAs? - Does this affect which NSAs receive a connection request? If so, how?
On Mar 10, 2011, at 12:03 PM, Jerry Sobieski wrote:
Hi Vangelis-
You are right except for one part:... As I see this, it is really only the NRM that cares about the endpoint name. NSI has no interest in what the endpoint string looks like other than maybe some purely aesthetic lexical conventions (e.g. no backspace characters, etc.) Therefore, the *NSI* protocol implementers must explicitly treat the string as just a string. If one domain wants to name its endpoints with topology info encoded, they can do that, but no other domain or NSA will look for that info in their string...as far as the other NSAs are concerned, the string is just a string.
I will say though that for the mapping of the NSI endpoint reference to the NRM resource *is* the responsibility of the implementors who are coding the PA frontend onto an NRM. They do need to know if local convention expects or requires local endpoints to be named a certain way. But again it is only relevant for the local endpoints, and so is only of local significance and only for that particular NRM. So this is not an NSI issue.
I recommend that we are explicit in the NSI standard and say the following: The <local part> of the endpoint reference is a string that uniquely identifies a particular endpoint within the <domain> specified. The NSI framework and protocol explicitly leave the value of the endpoint reference string to be assigned by the network domain within which the endpoint resides. The NSI Framework and protocol do not encode any information directly into the endpoint reference string.
How is that? This insures that local domains have full sway to name their own endpoints as they see fit.
Best regards Jerry
On 3/10/11 11:48 AM, Evangelos Chaniotakis wrote:
Jerry,
If I may distill your email to:
"Let's define an NSI-CS endpoint reference as this tuple: (globally unique domain identifier, locally scoped opaque identifier)."
I'm fine with that definition.
The actual implementation/representation/format of such a tuple should be left to the implementors of the protocol. It's just an ordered pair of strings, it does not deserve a big discussion about formats.
-- Evangelos Chaniotakis Network Engineer, ESnet Visit our blog: http://bit.ly/9mNapV
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
--- Inder Monga imonga@es.net
Yes, this is an important point. STP endpoint network NSA domain terminology should be defined before proceeding. "endpoint" and "domain" are the words we agreed to not to use. Tomohiro 2011/3/13 John MacAuley <john.macauley@surfnet.nl>:
Oops, forgot to make both components mandatory as Vangelis has. I guess I should have moved back in time :-)
Are we defining an STP or an endpoint? Are they the same and we are just changing terminology? I am a bit confused.
- Does a domain-id represent ownership/responsibility of the EPR by an NSA? - Can an EPR "belong to" multiple NSAs?
I think we are saying an endpoint belongs to a single domain, but I believe multiple NSA could manage the same domain, and therefore, the same endpoint.
- Does this affect which NSAs receive a connection request? If so, how?
Domain to NSA resolution is out of scope based on the last NSI call.
John.
On 2011-03-10, at 4:19 PM, Evangelos Chaniotakis wrote:
Jerry,
I disagree with part of what you're saying here: i.e. that the entire endpoint reference is a string. In my opinion the standard should define it is an abstract tuple: (domain-id, local-id).
The implementation of the standard should decide how to encode that tuple. It could be a pair of two XML elements for SOAP, or a colon- delimited concatenation, or whatever. It's absolutely trivial to go the extra mile and support multiple representations, converting between them on the fly.
Let me propose this schema snippet for the SOAP implementation:
<xsd:complexType name="nsiEndpointReference"> <xsd:sequence> <xsd:element name="domainId" type="xsd:string" maxOccurs="1" minOccurs="1"/> <xsd:element name="localId" type="xsd:string" maxOccurs="1" minOccurs="1"/> </xsd:sequence> </xsd:complexType>
I do agree with the points you're making about the local part, and I'm fine with the clarification you want to explicitly set in the standard.
In my opinion a much more important clarification needs to be made about the domain-id part. Here are some questions that should probably be answered.
- Does a domain-id represent ownership/responsibility of the EPR by an NSA? - Can an EPR "belong to" multiple NSAs? - Does this affect which NSAs receive a connection request? If so, how?
On Mar 10, 2011, at 12:03 PM, Jerry Sobieski wrote:
Hi Vangelis-
You are right except for one part:... As I see this, it is really only the NRM that cares about the endpoint name. NSI has no interest in what the endpoint string looks like other than maybe some purely aesthetic lexical conventions (e.g. no backspace characters, etc.) Therefore, the *NSI* protocol implementers must explicitly treat the string as just a string. If one domain wants to name its endpoints with topology info encoded, they can do that, but no other domain or NSA will look for that info in their string...as far as the other NSAs are concerned, the string is just a string.
I will say though that for the mapping of the NSI endpoint reference to the NRM resource *is* the responsibility of the implementors who are coding the PA frontend onto an NRM. They do need to know if local convention expects or requires local endpoints to be named a certain way. But again it is only relevant for the local endpoints, and so is only of local significance and only for that particular NRM. So this is not an NSI issue.
I recommend that we are explicit in the NSI standard and say the following: The <local part> of the endpoint reference is a string that uniquely identifies a particular endpoint within the <domain> specified. The NSI framework and protocol explicitly leave the value of the endpoint reference string to be assigned by the network domain within which the endpoint resides. The NSI Framework and protocol do not encode any information directly into the endpoint reference string.
How is that? This insures that local domains have full sway to name their own endpoints as they see fit.
Best regards Jerry
On 3/10/11 11:48 AM, Evangelos Chaniotakis wrote:
Jerry,
If I may distill your email to:
"Let's define an NSI-CS endpoint reference as this tuple: (globally unique domain identifier, locally scoped opaque identifier)."
I'm fine with that definition.
The actual implementation/representation/format of such a tuple should be left to the implementors of the protocol. It's just an ordered pair of strings, it does not deserve a big discussion about formats.
-- Evangelos Chaniotakis Network Engineer, ESnet Visit our blog: http://bit.ly/9mNapV
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Okay, i am glad it is not just me :-) On 2011-03-12, at 9:05 PM, Tomohiro Kudoh wrote:
Yes, this is an important point.
STP endpoint network NSA domain
terminology should be defined before proceeding.
"endpoint" and "domain" are the words we agreed to not to use.
Tomohiro
2011/3/13 John MacAuley <john.macauley@surfnet.nl>:
Oops, forgot to make both components mandatory as Vangelis has. I guess I should have moved back in time :-)
Are we defining an STP or an endpoint? Are they the same and we are just changing terminology? I am a bit confused.
- Does a domain-id represent ownership/responsibility of the EPR by an NSA? - Can an EPR "belong to" multiple NSAs?
I think we are saying an endpoint belongs to a single domain, but I believe multiple NSA could manage the same domain, and therefore, the same endpoint.
- Does this affect which NSAs receive a connection request? If so, how?
Domain to NSA resolution is out of scope based on the last NSI call.
John.
On 2011-03-10, at 4:19 PM, Evangelos Chaniotakis wrote:
Jerry,
I disagree with part of what you're saying here: i.e. that the entire endpoint reference is a string. In my opinion the standard should define it is an abstract tuple: (domain-id, local-id).
The implementation of the standard should decide how to encode that tuple. It could be a pair of two XML elements for SOAP, or a colon- delimited concatenation, or whatever. It's absolutely trivial to go the extra mile and support multiple representations, converting between them on the fly.
Let me propose this schema snippet for the SOAP implementation:
<xsd:complexType name="nsiEndpointReference"> <xsd:sequence> <xsd:element name="domainId" type="xsd:string" maxOccurs="1" minOccurs="1"/> <xsd:element name="localId" type="xsd:string" maxOccurs="1" minOccurs="1"/> </xsd:sequence> </xsd:complexType>
I do agree with the points you're making about the local part, and I'm fine with the clarification you want to explicitly set in the standard.
In my opinion a much more important clarification needs to be made about the domain-id part. Here are some questions that should probably be answered.
- Does a domain-id represent ownership/responsibility of the EPR by an NSA? - Can an EPR "belong to" multiple NSAs? - Does this affect which NSAs receive a connection request? If so, how?
On Mar 10, 2011, at 12:03 PM, Jerry Sobieski wrote:
Hi Vangelis-
You are right except for one part:... As I see this, it is really only the NRM that cares about the endpoint name. NSI has no interest in what the endpoint string looks like other than maybe some purely aesthetic lexical conventions (e.g. no backspace characters, etc.) Therefore, the *NSI* protocol implementers must explicitly treat the string as just a string. If one domain wants to name its endpoints with topology info encoded, they can do that, but no other domain or NSA will look for that info in their string...as far as the other NSAs are concerned, the string is just a string.
I will say though that for the mapping of the NSI endpoint reference to the NRM resource *is* the responsibility of the implementors who are coding the PA frontend onto an NRM. They do need to know if local convention expects or requires local endpoints to be named a certain way. But again it is only relevant for the local endpoints, and so is only of local significance and only for that particular NRM. So this is not an NSI issue.
I recommend that we are explicit in the NSI standard and say the following: The <local part> of the endpoint reference is a string that uniquely identifies a particular endpoint within the <domain> specified. The NSI framework and protocol explicitly leave the value of the endpoint reference string to be assigned by the network domain within which the endpoint resides. The NSI Framework and protocol do not encode any information directly into the endpoint reference string.
How is that? This insures that local domains have full sway to name their own endpoints as they see fit.
Best regards Jerry
On 3/10/11 11:48 AM, Evangelos Chaniotakis wrote:
Jerry,
If I may distill your email to:
"Let's define an NSI-CS endpoint reference as this tuple: (globally unique domain identifier, locally scoped opaque identifier)."
I'm fine with that definition.
The actual implementation/representation/format of such a tuple should be left to the implementors of the protocol. It's just an ordered pair of strings, it does not deserve a big discussion about formats.
-- Evangelos Chaniotakis Network Engineer, ESnet Visit our blog: http://bit.ly/9mNapV
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
I sent this to Inder last night. It is my summary of what an "STP" represents. Please read and offer comments. Jerry On 3/12/11 9:27 PM, John MacAuley wrote:
Okay, i am glad it is not just me :-)
On 2011-03-12, at 9:05 PM, Tomohiro Kudoh wrote:
Yes, this is an important point.
STP endpoint network NSA domain
terminology should be defined before proceeding.
"endpoint" and "domain" are the words we agreed to not to use.
Tomohiro
2011/3/13 John MacAuley<john.macauley@surfnet.nl>:
Oops, forgot to make both components mandatory as Vangelis has. I guess I should have moved back in time :-)
Are we defining an STP or an endpoint? Are they the same and we are just changing terminology? I am a bit confused.
- Does a domain-id represent ownership/responsibility of the EPR by an NSA? - Can an EPR "belong to" multiple NSAs? I think we are saying an endpoint belongs to a single domain, but I believe multiple NSA could manage the same domain, and therefore, the same endpoint.
- Does this affect which NSAs receive a connection request? If so, how? Domain to NSA resolution is out of scope based on the last NSI call.
John.
On 2011-03-10, at 4:19 PM, Evangelos Chaniotakis wrote:
Jerry,
I disagree with part of what you're saying here: i.e. that the entire endpoint reference is a string. In my opinion the standard should define it is an abstract tuple: (domain-id, local-id).
The implementation of the standard should decide how to encode that tuple. It could be a pair of two XML elements for SOAP, or a colon- delimited concatenation, or whatever. It's absolutely trivial to go the extra mile and support multiple representations, converting between them on the fly.
Let me propose this schema snippet for the SOAP implementation:
<xsd:complexType name="nsiEndpointReference"> <xsd:sequence> <xsd:element name="domainId" type="xsd:string" maxOccurs="1" minOccurs="1"/> <xsd:element name="localId" type="xsd:string" maxOccurs="1" minOccurs="1"/> </xsd:sequence> </xsd:complexType>
I do agree with the points you're making about the local part, and I'm fine with the clarification you want to explicitly set in the standard.
In my opinion a much more important clarification needs to be made about the domain-id part. Here are some questions that should probably be answered.
- Does a domain-id represent ownership/responsibility of the EPR by an NSA? - Can an EPR "belong to" multiple NSAs? - Does this affect which NSAs receive a connection request? If so, how?
On Mar 10, 2011, at 12:03 PM, Jerry Sobieski wrote:
Hi Vangelis-
You are right except for one part:... As I see this, it is really only the NRM that cares about the endpoint name. NSI has no interest in what the endpoint string looks like other than maybe some purely aesthetic lexical conventions (e.g. no backspace characters, etc.) Therefore, the *NSI* protocol implementers must explicitly treat the string as just a string. If one domain wants to name its endpoints with topology info encoded, they can do that, but no other domain or NSA will look for that info in their string...as far as the other NSAs are concerned, the string is just a string.
I will say though that for the mapping of the NSI endpoint reference to the NRM resource *is* the responsibility of the implementors who are coding the PA frontend onto an NRM. They do need to know if local convention expects or requires local endpoints to be named a certain way. But again it is only relevant for the local endpoints, and so is only of local significance and only for that particular NRM. So this is not an NSI issue.
I recommend that we are explicit in the NSI standard and say the following: The<local part> of the endpoint reference is a string that uniquely identifies a particular endpoint within the<domain> specified. The NSI framework and protocol explicitly leave the value of the endpoint reference string to be assigned by the network domain within which the endpoint resides. The NSI Framework and protocol do not encode any information directly into the endpoint reference string.
How is that? This insures that local domains have full sway to name their own endpoints as they see fit.
Best regards Jerry
On 3/10/11 11:48 AM, Evangelos Chaniotakis wrote:
Jerry,
If I may distill your email to:
"Let's define an NSI-CS endpoint reference as this tuple: (globally unique domain identifier, locally scoped opaque identifier)."
I'm fine with that definition.
The actual implementation/representation/format of such a tuple should be left to the implementors of the protocol. It's just an ordered pair of strings, it does not deserve a big discussion about formats.
-- Evangelos Chaniotakis Network Engineer, ESnet Visit our blog: http://bit.ly/9mNapV
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Jerry, So based on your definition below is STP == Endpoint Reference from an NSI protocol perspective? Definitions: Service Termination Point := 1. An abstract object that represents the ingress or egress point of a connection, or the abstract notion of a location in a topology where a connection could potentially originate or terminate. 2. A real point in a topology where a connection can originate or terminate. Endpoint := In NSI, this is a location within a network that can be used as an endpoint for a connection. Endpoint Reference := a two-tuple consisting of a {<network name>, <endpoint name>} . An “endpoint reference” is this tuple, the “endpoint” itself is the topological location it identifies. John.
Hi John- Yes. For NSI I think we can say an STP==endpoint. I think STPs in the abstract sense may be topological locations other than just a port or a VLAN, but for the purposes of NSI v1.0, I think a "real STP" is indeed a location in the topology where a connection may originate or terminate. (I note that I used a circular reference in the endpoint definition. Apologies. An Endpoint is the physical topological terminus of a connection.) I do reserve some flexibility in the abstraction however. I think there are ways we can use Service Termination Points to indicate larger complexes of topological elements. If folks are intersted I will elaborate, but for now, and to be expedient with respect to defining ReserveRequest() parameters, I suggest we accept an adequate definition and leave additional refinement to later. Is this helpful? Jerry On 3/12/11 9:57 PM, John MacAuley wrote:
Jerry,
So based on your definition below is STP == Endpoint Reference from an NSI protocol perspective?
Definitions:
*Service Termination Point*:= 1. An abstract object that represents the ingress or egress point of a connection, or the abstract notion of a location in a topology where a connection could potentially originate or terminate.2. A real point in a topology where a connection can originate or terminate.
*Endpoint *:= In NSI, this is a location within a network that can be used as an endpoint for a connection.
*Endpoint Reference*:= a two-tuple consisting of a {<network name>, <endpoint name>} .An “endpoint reference” is this tuple, the “endpoint” itself is the topological location it identifies.
John.
Taking Jerry's definition and Tomohiro's note not to use domain or endpoint I have defined the following three XML schema components: A "Path Object Type" consists of at a minimum an "aSTP" and a "zSTP", with an optional ordered list of "STP" defining the path through the network. An "STP Type" consisting of a mandatory "Network Id" string and a mandatory "Local Id" string that uniquely identify the STP. There is an optional "Order" attribute that will only be populated when the STP is part of the ordered list. An "STP List Type" that will support both an ordered and unordered list of STPs. So is does my definition of a Path Object cover what was intended in the CS architecture document? <xsd:complexType name="PathObjectType"> <xsd:sequence> <xsd:element name="aSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> <xsd:element name="orderedStpList" type="tns:StpListType" /> <xsd:element name="zSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="StpType"> <xsd:sequence> <xsd:element name="networkId" type="xsd:string" minOccurs="1" maxOccurs="1" /> <xsd:element name="localId" type="xsd:string" minOccurs="1" maxOccurs="1" /> </xsd:sequence> <xsd:attribute name="order" type="xsd:integer" /> </xsd:complexType> <xsd:complexType name="StpListType"> <xsd:sequence> <xsd:element name="stp" type="tns:StpType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType> On 2011-03-12, at 10:11 PM, Jerry Sobieski wrote:
Hi John-
Yes. For NSI I think we can say an STP==endpoint.
I think STPs in the abstract sense may be topological locations other than just a port or a VLAN, but for the purposes of NSI v1.0, I think a "real STP" is indeed a location in the topology where a connection may originate or terminate.
(I note that I used a circular reference in the endpoint definition. Apologies. An Endpoint is the physical topological terminus of a connection.) I do reserve some flexibility in the abstraction however. I think there are ways we can use Service Termination Points to indicate larger complexes of topological elements. If folks are intersted I will elaborate, but for now, and to be expedient with respect to defining ReserveRequest() parameters, I suggest we accept an adequate definition and leave additional refinement to later.
Is this helpful? Jerry
On 3/12/11 9:57 PM, John MacAuley wrote:
Jerry,
So based on your definition below is STP == Endpoint Reference from an NSI protocol perspective? Definitions:
Service Termination Point := 1. An abstract object that represents the ingress or egress point of a connection, or the abstract notion of a location in a topology where a connection could potentially originate or terminate. 2. A real point in a topology where a connection can originate or terminate.
Endpoint := In NSI, this is a location within a network that can be used as an endpoint for a connection.
Endpoint Reference := a two-tuple consisting of a {<network name>, <endpoint name>} . An “endpoint reference” is this tuple, the “endpoint” itself is the topological location it identifies.
John.
Hi John- I know we've had long discussions about path objects. But I am not so sure they are necessary... If we can make two concatenated connections and treat them as one, then why do we need to specify loose hops? We can instead just issue two reservation requests, right? If so, this would substantially simplify the request structure. And so far, I've not heard of any use case that multiple reservations would not work for transit routing. ?? Jerry On 3/12/11 10:35 PM, John MacAuley wrote:
Taking Jerry's definition and Tomohiro's note not to use domain or endpoint I have defined the following three XML schema components:
1. A "Path Object Type" consists of at a minimum an "aSTP" and a "zSTP", with an optional ordered list of "STP" defining the path through the network. 2. An "STP Type" consisting of a mandatory "Network Id" string and a mandatory "Local Id" string that uniquely identify the STP. There is an optional "Order" attribute that will only be populated when the STP is part of the ordered list. 3. An "STP List Type" that will support both an ordered and unordered list of STPs.
So is does my definition of a Path Object cover what was intended in the CS architecture document?
<xsd:complexTypename="PathObjectType"> <xsd:sequence> <xsd:elementname="aSTP"type="tns:StpType"minOccurs="1"maxOccurs="1"/> <xsd:elementname="orderedStpList"type="tns:StpListType"/> <xsd:elementname="zSTP"type="tns:StpType"minOccurs="1"maxOccurs="1"/> </xsd:sequence> </xsd:complexType>
<xsd:complexTypename="StpType"> <xsd:sequence> <xsd:elementname="networkId"type="xsd:string"minOccurs="1"maxOccurs="1"/> <xsd:elementname="localId"type="xsd:string"minOccurs="1"maxOccurs="1"/> </xsd:sequence> <xsd:attributename="order"type="xsd:integer"/> </xsd:complexType>
<xsd:complexTypename="StpListType"> <xsd:sequence> <xsd:elementname="stp"type="tns:StpType"minOccurs="0"maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
On 2011-03-12, at 10:11 PM, Jerry Sobieski wrote:
Hi John-
Yes. For NSI I think we can say an STP==endpoint.
I think STPs in the abstract sense may be topological locations other than just a port or a VLAN, but for the purposes of NSI v1.0, I think a "real STP" is indeed a location in the topology where a connection may originate or terminate.
(I note that I used a circular reference in the endpoint definition. Apologies. An Endpoint is the physical topological terminus of a connection.) I do reserve some flexibility in the abstraction however. I think there are ways we can use Service Termination Points to indicate larger complexes of topological elements. If folks are intersted I will elaborate, but for now, and to be expedient with respect to defining ReserveRequest() parameters, I suggest we accept an adequate definition and leave additional refinement to later.
Is this helpful? Jerry
On 3/12/11 9:57 PM, John MacAuley wrote:
Jerry,
So based on your definition below is STP == Endpoint Reference from an NSI protocol perspective?
Definitions:
*Service Termination Point*:= 1. An abstract object that represents the ingress or egress point of a connection, or the abstract notion of a location in a topology where a connection could potentially originate or terminate.2. A real point in a topology where a connection can originate or terminate.
*Endpoint *:= In NSI, this is a location within a network that can be used as an endpoint for a connection.
*Endpoint Reference*:= a two-tuple consisting of a {<network name>, <endpoint name>} .An “endpoint reference” is this tuple, the “endpoint” itself is the topological location it identifies.
John.
I am okay not to specify anything other than the source and destination, but was this not the whole discussion around not routing traffic through certain locations by specifying the route? It resulted in the trust discussion. Does anyone else have strong opinions on the topic? John. On 2011-03-12, at 11:42 PM, Jerry Sobieski wrote:
Hi John- I know we've had long discussions about path objects. But I am not so sure they are necessary...
If we can make two concatenated connections and treat them as one, then why do we need to specify loose hops? We can instead just issue two reservation requests, right? If so, this would substantially simplify the request structure. And so far, I've not heard of any use case that multiple reservations would not work for transit routing.
??
Jerry
On 3/12/11 10:35 PM, John MacAuley wrote:
Taking Jerry's definition and Tomohiro's note not to use domain or endpoint I have defined the following three XML schema components:
A "Path Object Type" consists of at a minimum an "aSTP" and a "zSTP", with an optional ordered list of "STP" defining the path through the network. An "STP Type" consisting of a mandatory "Network Id" string and a mandatory "Local Id" string that uniquely identify the STP. There is an optional "Order" attribute that will only be populated when the STP is part of the ordered list. An "STP List Type" that will support both an ordered and unordered list of STPs.
So is does my definition of a Path Object cover what was intended in the CS architecture document?
<xsd:complexType name="PathObjectType"> <xsd:sequence> <xsd:element name="aSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> <xsd:element name="orderedStpList" type="tns:StpListType" /> <xsd:element name="zSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="StpType"> <xsd:sequence> <xsd:element name="networkId" type="xsd:string" minOccurs="1" maxOccurs="1" /> <xsd:element name="localId" type="xsd:string" minOccurs="1" maxOccurs="1" /> </xsd:sequence> <xsd:attribute name="order" type="xsd:integer" /> </xsd:complexType>
<xsd:complexType name="StpListType"> <xsd:sequence> <xsd:element name="stp" type="tns:StpType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType>
On 2011-03-12, at 10:11 PM, Jerry Sobieski wrote:
Hi John-
Yes. For NSI I think we can say an STP==endpoint.
I think STPs in the abstract sense may be topological locations other than just a port or a VLAN, but for the purposes of NSI v1.0, I think a "real STP" is indeed a location in the topology where a connection may originate or terminate.
(I note that I used a circular reference in the endpoint definition. Apologies. An Endpoint is the physical topological terminus of a connection.) I do reserve some flexibility in the abstraction however. I think there are ways we can use Service Termination Points to indicate larger complexes of topological elements. If folks are intersted I will elaborate, but for now, and to be expedient with respect to defining ReserveRequest() parameters, I suggest we accept an adequate definition and leave additional refinement to later.
Is this helpful? Jerry
On 3/12/11 9:57 PM, John MacAuley wrote:
Jerry,
So based on your definition below is STP == Endpoint Reference from an NSI protocol perspective? Definitions:
Service Termination Point := 1. An abstract object that represents the ingress or egress point of a connection, or the abstract notion of a location in a topology where a connection could potentially originate or terminate. 2. A real point in a topology where a connection can originate or terminate.
Endpoint := In NSI, this is a location within a network that can be used as an endpoint for a connection.
Endpoint Reference := a two-tuple consisting of a {<network name>, <endpoint name>} . An “endpoint reference” is this tuple, the “endpoint” itself is the topological location it identifies.
John.
I'm fine just specifying the source and destination in the initial implementation. However I think that as we evolve the protocol, being able to specify "mid-point" STPs will be useful. If I recall correctly, the issue was that the end user may not be able to see the "mid-point" STPs and thus is unable to verify the path. However as we start adding other services (i.e. monitoring, etc), lack of visibility may not be an issue. - Chin --On March 12, 2011 11:51:20 PM -0500 John MacAuley <john.macauley@surfnet.nl> wrote:
I am okay not to specify anything other than the source and destination, but was this not the whole discussion around not routing traffic through certain locations by specifying the route? It resulted in the trust discussion.
Does anyone else have strong opinions on the topic?
John.
On 2011-03-12, at 11:42 PM, Jerry Sobieski wrote:
Hi John- I know we've had long discussions about path objects. But I am not so sure they are necessary...
If we can make two concatenated connections and treat them as one, then why do we need to specify loose hops? We can instead just issue two reservation requests, right? If so, this would substantially simplify the request structure. And so far, I've not heard of any use case that multiple reservations would not work for transit routing.
??
Jerry
On 3/12/11 10:35 PM, John MacAuley wrote:
Taking Jerry's definition and Tomohiro's note not to use domain or endpoint I have defined the following three XML schema components:
• A "Path Object Type" consists of at a minimum an "aSTP" and a "zSTP", with an optional ordered list of "STP" defining the path through the network. • An "STP Type" consisting of a mandatory "Network Id" string and a mandatory "Local Id" string that uniquely identify the STP. There is an optional "Order" attribute that will only be populated when the STP is part of the ordered list. • An "STP List Type" that will support both an ordered and unordered list of STPs.
So is does my definition of a Path Object cover what was intended in the CS architecture document?
<xsd:complexType name="PathObjectType"> <xsd:sequence> <xsd:element name="aSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> <xsd:element name="orderedStpList" type="tns:StpListType" /> <xsd:element name="zSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="StpType"> <xsd:sequence> <xsd:element name="networkId" type="xsd:string" minOccurs="1" maxOccurs="1" /> <xsd:element name="localId" type="xsd:string" minOccurs="1" maxOccurs="1" /> </xsd:sequence> <xsd:attribute name="order" type="xsd:integer" /> </xsd:complexType>
<xsd:complexType name="StpListType"> <xsd:sequence> <xsd:element name="stp" type="tns:StpType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType>
On 2011-03-12, at 10:11 PM, Jerry Sobieski wrote:
Hi John-
Yes. For NSI I think we can say an STP==endpoint.
I think STPs in the abstract sense may be topological locations other than just a port or a VLAN, but for the purposes of NSI v1.0, I think a "real STP" is indeed a location in the topology where a connection may originate or terminate.
(I note that I used a circular reference in the endpoint definition. Apologies. An Endpoint is the physical topological terminus of a connection.) I do reserve some flexibility in the abstraction however. I think there are ways we can use Service Termination Points to indicate larger complexes of topological elements. If folks are intersted I will elaborate, but for now, and to be expedient with respect to defining ReserveRequest() parameters, I suggest we accept an adequate definition and leave additional refinement to later.
Is this helpful? Jerry
On 3/12/11 9:57 PM, John MacAuley wrote:
Jerry,
So based on your definition below is STP == Endpoint Reference from an NSI protocol perspective?
Definitions:
Service Termination Point := 1. An abstract object that represents the ingress or egress point of a connection, or the abstract notion of a location in a topology where a connection could potentially originate or terminate. 2. A real point in a topology where a connection can originate or terminate.
Endpoint := In NSI, this is a location within a network that can be used as an endpoint for a connection.
Endpoint Reference := a two-tuple consisting of a {<network name>, <endpoint name>} . An “endpoint reference” is this tuple, the “endpoint” itself is the topological location it identifies.
John.
If we remove the hop-by-hop capabilities from the reservation request, do I also remove it from any queries? On 2011-03-13, at 1:06 PM, Chin Guok wrote:
I'm fine just specifying the source and destination in the initial implementation. However I think that as we evolve the protocol, being able to specify "mid-point" STPs will be useful.
If I recall correctly, the issue was that the end user may not be able to see the "mid-point" STPs and thus is unable to verify the path. However as we start adding other services (i.e. monitoring, etc), lack of visibility may not be an issue.
- Chin
--On March 12, 2011 11:51:20 PM -0500 John MacAuley <john.macauley@surfnet.nl> wrote:
I am okay not to specify anything other than the source and destination, but was this not the whole discussion around not routing traffic through certain locations by specifying the route? It resulted in the trust discussion.
Does anyone else have strong opinions on the topic?
John.
On 2011-03-12, at 11:42 PM, Jerry Sobieski wrote:
Hi John- I know we've had long discussions about path objects. But I am not so sure they are necessary...
If we can make two concatenated connections and treat them as one, then why do we need to specify loose hops? We can instead just issue two reservation requests, right? If so, this would substantially simplify the request structure. And so far, I've not heard of any use case that multiple reservations would not work for transit routing.
??
Jerry
On 3/12/11 10:35 PM, John MacAuley wrote:
Taking Jerry's definition and Tomohiro's note not to use domain or endpoint I have defined the following three XML schema components:
• A "Path Object Type" consists of at a minimum an "aSTP" and a "zSTP", with an optional ordered list of "STP" defining the path through the network. • An "STP Type" consisting of a mandatory "Network Id" string and a mandatory "Local Id" string that uniquely identify the STP. There is an optional "Order" attribute that will only be populated when the STP is part of the ordered list. • An "STP List Type" that will support both an ordered and unordered list of STPs.
So is does my definition of a Path Object cover what was intended in the CS architecture document?
<xsd:complexType name="PathObjectType"> <xsd:sequence> <xsd:element name="aSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> <xsd:element name="orderedStpList" type="tns:StpListType" /> <xsd:element name="zSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="StpType"> <xsd:sequence> <xsd:element name="networkId" type="xsd:string" minOccurs="1" maxOccurs="1" /> <xsd:element name="localId" type="xsd:string" minOccurs="1" maxOccurs="1" /> </xsd:sequence> <xsd:attribute name="order" type="xsd:integer" /> </xsd:complexType>
<xsd:complexType name="StpListType"> <xsd:sequence> <xsd:element name="stp" type="tns:StpType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType>
On 2011-03-12, at 10:11 PM, Jerry Sobieski wrote:
Hi John-
Yes. For NSI I think we can say an STP==endpoint.
I think STPs in the abstract sense may be topological locations other than just a port or a VLAN, but for the purposes of NSI v1.0, I think a "real STP" is indeed a location in the topology where a connection may originate or terminate.
(I note that I used a circular reference in the endpoint definition. Apologies. An Endpoint is the physical topological terminus of a connection.) I do reserve some flexibility in the abstraction however. I think there are ways we can use Service Termination Points to indicate larger complexes of topological elements. If folks are intersted I will elaborate, but for now, and to be expedient with respect to defining ReserveRequest() parameters, I suggest we accept an adequate definition and leave additional refinement to later.
Is this helpful? Jerry
On 3/12/11 9:57 PM, John MacAuley wrote:
Jerry,
So based on your definition below is STP == Endpoint Reference from an NSI protocol perspective?
Definitions:
Service Termination Point := 1. An abstract object that represents the ingress or egress point of a connection, or the abstract notion of a location in a topology where a connection could potentially originate or terminate. 2. A real point in a topology where a connection can originate or terminate.
Endpoint := In NSI, this is a location within a network that can be used as an endpoint for a connection.
Endpoint Reference := a two-tuple consisting of a {<network name>, <endpoint name>} . An “endpoint reference” is this tuple, the “endpoint” itself is the topological location it identifies.
John.
Sorry, I should have stated the reservation and query responses. On 2011-03-13, at 12:29 PM, John MacAuley wrote:
If we remove the hop-by-hop capabilities from the reservation request, do I also remove it from any queries?
On 2011-03-13, at 1:06 PM, Chin Guok wrote:
I'm fine just specifying the source and destination in the initial implementation. However I think that as we evolve the protocol, being able to specify "mid-point" STPs will be useful.
If I recall correctly, the issue was that the end user may not be able to see the "mid-point" STPs and thus is unable to verify the path. However as we start adding other services (i.e. monitoring, etc), lack of visibility may not be an issue.
- Chin
--On March 12, 2011 11:51:20 PM -0500 John MacAuley <john.macauley@surfnet.nl> wrote:
I am okay not to specify anything other than the source and destination, but was this not the whole discussion around not routing traffic through certain locations by specifying the route? It resulted in the trust discussion.
Does anyone else have strong opinions on the topic?
John.
On 2011-03-12, at 11:42 PM, Jerry Sobieski wrote:
Hi John- I know we've had long discussions about path objects. But I am not so sure they are necessary...
If we can make two concatenated connections and treat them as one, then why do we need to specify loose hops? We can instead just issue two reservation requests, right? If so, this would substantially simplify the request structure. And so far, I've not heard of any use case that multiple reservations would not work for transit routing.
??
Jerry
On 3/12/11 10:35 PM, John MacAuley wrote:
Taking Jerry's definition and Tomohiro's note not to use domain or endpoint I have defined the following three XML schema components:
• A "Path Object Type" consists of at a minimum an "aSTP" and a "zSTP", with an optional ordered list of "STP" defining the path through the network. • An "STP Type" consisting of a mandatory "Network Id" string and a mandatory "Local Id" string that uniquely identify the STP. There is an optional "Order" attribute that will only be populated when the STP is part of the ordered list. • An "STP List Type" that will support both an ordered and unordered list of STPs.
So is does my definition of a Path Object cover what was intended in the CS architecture document?
<xsd:complexType name="PathObjectType"> <xsd:sequence> <xsd:element name="aSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> <xsd:element name="orderedStpList" type="tns:StpListType" /> <xsd:element name="zSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="StpType"> <xsd:sequence> <xsd:element name="networkId" type="xsd:string" minOccurs="1" maxOccurs="1" /> <xsd:element name="localId" type="xsd:string" minOccurs="1" maxOccurs="1" /> </xsd:sequence> <xsd:attribute name="order" type="xsd:integer" /> </xsd:complexType>
<xsd:complexType name="StpListType"> <xsd:sequence> <xsd:element name="stp" type="tns:StpType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType>
On 2011-03-12, at 10:11 PM, Jerry Sobieski wrote:
Hi John-
Yes. For NSI I think we can say an STP==endpoint.
I think STPs in the abstract sense may be topological locations other than just a port or a VLAN, but for the purposes of NSI v1.0, I think a "real STP" is indeed a location in the topology where a connection may originate or terminate.
(I note that I used a circular reference in the endpoint definition. Apologies. An Endpoint is the physical topological terminus of a connection.) I do reserve some flexibility in the abstraction however. I think there are ways we can use Service Termination Points to indicate larger complexes of topological elements. If folks are intersted I will elaborate, but for now, and to be expedient with respect to defining ReserveRequest() parameters, I suggest we accept an adequate definition and leave additional refinement to later.
Is this helpful? Jerry
On 3/12/11 9:57 PM, John MacAuley wrote:
Jerry,
So based on your definition below is STP == Endpoint Reference from an NSI protocol perspective?
Definitions:
Service Termination Point := 1. An abstract object that represents the ingress or egress point of a connection, or the abstract notion of a location in a topology where a connection could potentially originate or terminate. 2. A real point in a topology where a connection can originate or terminate.
Endpoint := In NSI, this is a location within a network that can be used as an endpoint for a connection.
Endpoint Reference := a two-tuple consisting of a {<network name>, <endpoint name>} . An “endpoint reference” is this tuple, the “endpoint” itself is the topological location it identifies.
John.
My vote is to keep the hop-by-hop info in the reservation request, and return it in queries.
From a practical standpoint, as we start using the protocol not only as an academic exercise but as a production tool, having that level of detail is critical in helping network operators troubleshoot (i.e. determining which downstream network to contact).
My 2 cents. - Chin --On March 13, 2011 12:30:16 PM -0400 John MacAuley <john.macauley@surfnet.nl> wrote:
Sorry, I should have stated the reservation and query responses.
On 2011-03-13, at 12:29 PM, John MacAuley wrote:
If we remove the hop-by-hop capabilities from the reservation request, do I also remove it from any queries?
On 2011-03-13, at 1:06 PM, Chin Guok wrote:
I'm fine just specifying the source and destination in the initial implementation. However I think that as we evolve the protocol, being able to specify "mid-point" STPs will be useful.
If I recall correctly, the issue was that the end user may not be able to see the "mid-point" STPs and thus is unable to verify the path. However as we start adding other services (i.e. monitoring, etc), lack of visibility may not be an issue.
- Chin
--On March 12, 2011 11:51:20 PM -0500 John MacAuley <john.macauley@surfnet.nl> wrote:
I am okay not to specify anything other than the source and destination, but was this not the whole discussion around not routing traffic through certain locations by specifying the route? It resulted in the trust discussion.
Does anyone else have strong opinions on the topic?
John.
On 2011-03-12, at 11:42 PM, Jerry Sobieski wrote:
Hi John- I know we've had long discussions about path objects. But I am not so sure they are necessary...
If we can make two concatenated connections and treat them as one, then why do we need to specify loose hops? We can instead just issue two reservation requests, right? If so, this would substantially simplify the request structure. And so far, I've not heard of any use case that multiple reservations would not work for transit routing.
??
Jerry
On 3/12/11 10:35 PM, John MacAuley wrote:
Taking Jerry's definition and Tomohiro's note not to use domain or endpoint I have defined the following three XML schema components:
• A "Path Object Type" consists of at a minimum an "aSTP" and a "zSTP", with an optional ordered list of "STP" defining the path through the network. • An "STP Type" consisting of a mandatory "Network Id" string and a mandatory "Local Id" string that uniquely identify the STP. There is an optional "Order" attribute that will only be populated when the STP is part of the ordered list. • An "STP List Type" that will support both an ordered and unordered list of STPs.
So is does my definition of a Path Object cover what was intended in the CS architecture document?
<xsd:complexType name="PathObjectType"> <xsd:sequence> <xsd:element name="aSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> <xsd:element name="orderedStpList" type="tns:StpListType" /> <xsd:element name="zSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="StpType"> <xsd:sequence> <xsd:element name="networkId" type="xsd:string" minOccurs="1" maxOccurs="1" /> <xsd:element name="localId" type="xsd:string" minOccurs="1" maxOccurs="1" /> </xsd:sequence> <xsd:attribute name="order" type="xsd:integer" /> </xsd:complexType>
<xsd:complexType name="StpListType"> <xsd:sequence> <xsd:element name="stp" type="tns:StpType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType>
On 2011-03-12, at 10:11 PM, Jerry Sobieski wrote:
Hi John-
Yes. For NSI I think we can say an STP==endpoint.
I think STPs in the abstract sense may be topological locations other than just a port or a VLAN, but for the purposes of NSI v1.0, I think a "real STP" is indeed a location in the topology where a connection may originate or terminate.
(I note that I used a circular reference in the endpoint definition. Apologies. An Endpoint is the physical topological terminus of a connection.) I do reserve some flexibility in the abstraction however. I think there are ways we can use Service Termination Points to indicate larger complexes of topological elements. If folks are intersted I will elaborate, but for now, and to be expedient with respect to defining ReserveRequest() parameters, I suggest we accept an adequate definition and leave additional refinement to later.
Is this helpful? Jerry
On 3/12/11 9:57 PM, John MacAuley wrote:
Jerry,
So based on your definition below is STP == Endpoint Reference from an NSI protocol perspective?
Definitions:
Service Termination Point := 1. An abstract object that represents the ingress or egress point of a connection, or the abstract notion of a location in a topology where a connection could potentially originate or terminate. 2. A real point in a topology where a connection can originate or terminate.
Endpoint := In NSI, this is a location within a network that can be used as an endpoint for a connection.
Endpoint Reference := a two-tuple consisting of a {<network name>, <endpoint name>} . An “endpoint reference” is this tuple, the “endpoint” itself is the topological location it identifies.
John.
I think we had agreed at GLIF that queries would be (for now) just returning the PA's state and the request parameters as-built. That there was no walking the tree implied at this time...? J On 3/13/11 12:29 PM, John MacAuley wrote:
If we remove the hop-by-hop capabilities from the reservation request, do I also remove it from any queries?
On 2011-03-13, at 1:06 PM, Chin Guok wrote:
I'm fine just specifying the source and destination in the initial implementation. However I think that as we evolve the protocol, being able to specify "mid-point" STPs will be useful.
If I recall correctly, the issue was that the end user may not be able to see the "mid-point" STPs and thus is unable to verify the path. However as we start adding other services (i.e. monitoring, etc), lack of visibility may not be an issue.
- Chin
--On March 12, 2011 11:51:20 PM -0500 John MacAuley<john.macauley@surfnet.nl> wrote:
I am okay not to specify anything other than the source and destination, but was this not the whole discussion around not routing traffic through certain locations by specifying the route? It resulted in the trust discussion.
Does anyone else have strong opinions on the topic?
John.
On 2011-03-12, at 11:42 PM, Jerry Sobieski wrote:
Hi John- I know we've had long discussions about path objects. But I am not so sure they are necessary...
If we can make two concatenated connections and treat them as one, then why do we need to specify loose hops? We can instead just issue two reservation requests, right? If so, this would substantially simplify the request structure. And so far, I've not heard of any use case that multiple reservations would not work for transit routing.
??
Jerry
On 3/12/11 10:35 PM, John MacAuley wrote:
Taking Jerry's definition and Tomohiro's note not to use domain or endpoint I have defined the following three XML schema components:
• A "Path Object Type" consists of at a minimum an "aSTP" and a "zSTP", with an optional ordered list of "STP" defining the path through the network. • An "STP Type" consisting of a mandatory "Network Id" string and a mandatory "Local Id" string that uniquely identify the STP. There is an optional "Order" attribute that will only be populated when the STP is part of the ordered list. • An "STP List Type" that will support both an ordered and unordered list of STPs.
So is does my definition of a Path Object cover what was intended in the CS architecture document?
<xsd:complexType name="PathObjectType"> <xsd:sequence> <xsd:element name="aSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> <xsd:element name="orderedStpList" type="tns:StpListType" /> <xsd:element name="zSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="StpType"> <xsd:sequence> <xsd:element name="networkId" type="xsd:string" minOccurs="1" maxOccurs="1" /> <xsd:element name="localId" type="xsd:string" minOccurs="1" maxOccurs="1" /> </xsd:sequence> <xsd:attribute name="order" type="xsd:integer" /> </xsd:complexType>
<xsd:complexType name="StpListType"> <xsd:sequence> <xsd:element name="stp" type="tns:StpType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType>
On 2011-03-12, at 10:11 PM, Jerry Sobieski wrote:
Hi John-
Yes. For NSI I think we can say an STP==endpoint.
I think STPs in the abstract sense may be topological locations other than just a port or a VLAN, but for the purposes of NSI v1.0, I think a "real STP" is indeed a location in the topology where a connection may originate or terminate.
(I note that I used a circular reference in the endpoint definition. Apologies. An Endpoint is the physical topological terminus of a connection.) I do reserve some flexibility in the abstraction however. I think there are ways we can use Service Termination Points to indicate larger complexes of topological elements. If folks are intersted I will elaborate, but for now, and to be expedient with respect to defining ReserveRequest() parameters, I suggest we accept an adequate definition and leave additional refinement to later.
Is this helpful? Jerry
On 3/12/11 9:57 PM, John MacAuley wrote:
Jerry,
So based on your definition below is STP == Endpoint Reference from an NSI protocol perspective?
Definitions:
Service Termination Point := 1. An abstract object that represents the ingress or egress point of a connection, or the abstract notion of a location in a topology where a connection could potentially originate or terminate. 2. A real point in a topology where a connection can originate or terminate.
Endpoint := In NSI, this is a location within a network that can be used as an endpoint for a connection.
Endpoint Reference := a two-tuple consisting of a {<network name>, <endpoint name>} . An “endpoint reference” is this tuple, the “endpoint” itself is the topological location it identifies.
John.
Returning the hop-by-hop capabilities does not necessarily imply walking the tree. Inder On Mar 14, 2011, at 7:50 AM, Jerry Sobieski wrote:
I think we had agreed at GLIF that queries would be (for now) just returning the PA's state and the request parameters as-built. That there was no walking the tree implied at this time...?
J
On 3/13/11 12:29 PM, John MacAuley wrote:
If we remove the hop-by-hop capabilities from the reservation request, do I also remove it from any queries?
On 2011-03-13, at 1:06 PM, Chin Guok wrote:
I'm fine just specifying the source and destination in the initial implementation. However I think that as we evolve the protocol, being able to specify "mid-point" STPs will be useful.
If I recall correctly, the issue was that the end user may not be able to see the "mid-point" STPs and thus is unable to verify the path. However as we start adding other services (i.e. monitoring, etc), lack of visibility may not be an issue.
- Chin
--On March 12, 2011 11:51:20 PM -0500 John MacAuley<john.macauley@surfnet.nl> wrote:
I am okay not to specify anything other than the source and destination, but was this not the whole discussion around not routing traffic through certain locations by specifying the route? It resulted in the trust discussion.
Does anyone else have strong opinions on the topic?
John.
On 2011-03-12, at 11:42 PM, Jerry Sobieski wrote:
Hi John- I know we've had long discussions about path objects. But I am not so sure they are necessary...
If we can make two concatenated connections and treat them as one, then why do we need to specify loose hops? We can instead just issue two reservation requests, right? If so, this would substantially simplify the request structure. And so far, I've not heard of any use case that multiple reservations would not work for transit routing.
??
Jerry
On 3/12/11 10:35 PM, John MacAuley wrote:
Taking Jerry's definition and Tomohiro's note not to use domain or endpoint I have defined the following three XML schema components:
• A "Path Object Type" consists of at a minimum an "aSTP" and a "zSTP", with an optional ordered list of "STP" defining the path through the network. • An "STP Type" consisting of a mandatory "Network Id" string and a mandatory "Local Id" string that uniquely identify the STP. There is an optional "Order" attribute that will only be populated when the STP is part of the ordered list. • An "STP List Type" that will support both an ordered and unordered list of STPs.
So is does my definition of a Path Object cover what was intended in the CS architecture document?
<xsd:complexType name="PathObjectType"> <xsd:sequence> <xsd:element name="aSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> <xsd:element name="orderedStpList" type="tns:StpListType" /> <xsd:element name="zSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="StpType"> <xsd:sequence> <xsd:element name="networkId" type="xsd:string" minOccurs="1" maxOccurs="1" /> <xsd:element name="localId" type="xsd:string" minOccurs="1" maxOccurs="1" /> </xsd:sequence> <xsd:attribute name="order" type="xsd:integer" /> </xsd:complexType>
<xsd:complexType name="StpListType"> <xsd:sequence> <xsd:element name="stp" type="tns:StpType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType>
On 2011-03-12, at 10:11 PM, Jerry Sobieski wrote:
Hi John-
Yes. For NSI I think we can say an STP==endpoint.
I think STPs in the abstract sense may be topological locations other than just a port or a VLAN, but for the purposes of NSI v1.0, I think a "real STP" is indeed a location in the topology where a connection may originate or terminate.
(I note that I used a circular reference in the endpoint definition. Apologies. An Endpoint is the physical topological terminus of a connection.) I do reserve some flexibility in the abstraction however. I think there are ways we can use Service Termination Points to indicate larger complexes of topological elements. If folks are intersted I will elaborate, but for now, and to be expedient with respect to defining ReserveRequest() parameters, I suggest we accept an adequate definition and leave additional refinement to later.
Is this helpful? Jerry
On 3/12/11 9:57 PM, John MacAuley wrote:
Jerry,
So based on your definition below is STP == Endpoint Reference from an NSI protocol perspective?
Definitions:
Service Termination Point := 1. An abstract object that represents the ingress or egress point of a connection, or the abstract notion of a location in a topology where a connection could potentially originate or terminate. 2. A real point in a topology where a connection can originate or terminate.
Endpoint := In NSI, this is a location within a network that can be used as an endpoint for a connection.
Endpoint Reference := a two-tuple consisting of a {<network name>, <endpoint name>} . An “endpoint reference” is this tuple, the “endpoint” itself is the topological location it identifies.
John.
nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
--- Inder Monga imonga@es.net
Hmm...maybe I am confused... (not often:-) What hop by hop aspects are we speaking to? J On 3/14/11 12:21 PM, Inder Monga wrote:
Returning the hop-by-hop capabilities does not necessarily imply walking the tree.
Inder
On Mar 14, 2011, at 7:50 AM, Jerry Sobieski wrote:
I think we had agreed at GLIF that queries would be (for now) just returning the PA's state and the request parameters as-built. That there was no walking the tree implied at this time...?
J
On 3/13/11 12:29 PM, John MacAuley wrote:
If we remove the hop-by-hop capabilities from the reservation request, do I also remove it from any queries?
On 2011-03-13, at 1:06 PM, Chin Guok wrote:
I'm fine just specifying the source and destination in the initial implementation. However I think that as we evolve the protocol, being able to specify "mid-point" STPs will be useful.
If I recall correctly, the issue was that the end user may not be able to see the "mid-point" STPs and thus is unable to verify the path. However as we start adding other services (i.e. monitoring, etc), lack of visibility may not be an issue.
- Chin
--On March 12, 2011 11:51:20 PM -0500 John MacAuley<john.macauley@surfnet.nl> wrote:
I am okay not to specify anything other than the source and destination, but was this not the whole discussion around not routing traffic through certain locations by specifying the route? It resulted in the trust discussion.
Does anyone else have strong opinions on the topic?
John.
On 2011-03-12, at 11:42 PM, Jerry Sobieski wrote:
Hi John- I know we've had long discussions about path objects. But I am not so sure they are necessary...
If we can make two concatenated connections and treat them as one, then why do we need to specify loose hops? We can instead just issue two reservation requests, right? If so, this would substantially simplify the request structure. And so far, I've not heard of any use case that multiple reservations would not work for transit routing.
??
Jerry
On 3/12/11 10:35 PM, John MacAuley wrote:
Taking Jerry's definition and Tomohiro's note not to use domain or endpoint I have defined the following three XML schema components:
• A "Path Object Type" consists of at a minimum an "aSTP" and a "zSTP", with an optional ordered list of "STP" defining the path through the network. • An "STP Type" consisting of a mandatory "Network Id" string and a mandatory "Local Id" string that uniquely identify the STP. There is an optional "Order" attribute that will only be populated when the STP is part of the ordered list. • An "STP List Type" that will support both an ordered and unordered list of STPs.
So is does my definition of a Path Object cover what was intended in the CS architecture document?
<xsd:complexType name="PathObjectType"> <xsd:sequence> <xsd:element name="aSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> <xsd:element name="orderedStpList" type="tns:StpListType" /> <xsd:element name="zSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="StpType"> <xsd:sequence> <xsd:element name="networkId" type="xsd:string" minOccurs="1" maxOccurs="1" /> <xsd:element name="localId" type="xsd:string" minOccurs="1" maxOccurs="1" /> </xsd:sequence> <xsd:attribute name="order" type="xsd:integer" /> </xsd:complexType>
<xsd:complexType name="StpListType"> <xsd:sequence> <xsd:element name="stp" type="tns:StpType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType>
On 2011-03-12, at 10:11 PM, Jerry Sobieski wrote:
Hi John-
Yes. For NSI I think we can say an STP==endpoint.
I think STPs in the abstract sense may be topological locations other than just a port or a VLAN, but for the purposes of NSI v1.0, I think a "real STP" is indeed a location in the topology where a connection may originate or terminate.
(I note that I used a circular reference in the endpoint definition. Apologies. An Endpoint is the physical topological terminus of a connection.) I do reserve some flexibility in the abstraction however. I think there are ways we can use Service Termination Points to indicate larger complexes of topological elements. If folks are intersted I will elaborate, but for now, and to be expedient with respect to defining ReserveRequest() parameters, I suggest we accept an adequate definition and leave additional refinement to later.
Is this helpful? Jerry
On 3/12/11 9:57 PM, John MacAuley wrote:
Jerry,
So based on your definition below is STP == Endpoint Reference from an NSI protocol perspective?
Definitions:
Service Termination Point := 1. An abstract object that represents the ingress or egress point of a connection, or the abstract notion of a location in a topology where a connection could potentially originate or terminate. 2. A real point in a topology where a connection can originate or terminate.
Endpoint := In NSI, this is a location within a network that can be used as an endpoint for a connection.
Endpoint Reference := a two-tuple consisting of a {<network name>, <endpoint name>} . An “endpoint reference” is this tuple, the “endpoint” itself is the topological location it identifies.
John.
nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Inder Monga imonga@es.net
or maybe I am confused, either way - The PA's state and request parameters as-built - the request parameters as built may have the abstract representation of the various "segments" of the call with any information that may be shared. Is that what I am assuming for "hop by hop" information. but this may not be what Chin/John had been meaning in their responses. Inder On Mar 14, 2011, at 9:28 AM, Jerry Sobieski wrote:
Hmm...maybe I am confused... (not often:-)
What hop by hop aspects are we speaking to?
J
On 3/14/11 12:21 PM, Inder Monga wrote:
Returning the hop-by-hop capabilities does not necessarily imply walking the tree.
Inder
On Mar 14, 2011, at 7:50 AM, Jerry Sobieski wrote:
I think we had agreed at GLIF that queries would be (for now) just returning the PA's state and the request parameters as-built. That there was no walking the tree implied at this time...?
J
On 3/13/11 12:29 PM, John MacAuley wrote:
If we remove the hop-by-hop capabilities from the reservation request, do I also remove it from any queries?
On 2011-03-13, at 1:06 PM, Chin Guok wrote:
I'm fine just specifying the source and destination in the initial implementation. However I think that as we evolve the protocol, being able to specify "mid-point" STPs will be useful.
If I recall correctly, the issue was that the end user may not be able to see the "mid-point" STPs and thus is unable to verify the path. However as we start adding other services (i.e. monitoring, etc), lack of visibility may not be an issue.
- Chin
--On March 12, 2011 11:51:20 PM -0500 John MacAuley<john.macauley@surfnet.nl> wrote:
I am okay not to specify anything other than the source and destination, but was this not the whole discussion around not routing traffic through certain locations by specifying the route? It resulted in the trust discussion.
Does anyone else have strong opinions on the topic?
John.
On 2011-03-12, at 11:42 PM, Jerry Sobieski wrote:
Hi John- I know we've had long discussions about path objects. But I am not so sure they are necessary...
If we can make two concatenated connections and treat them as one, then why do we need to specify loose hops? We can instead just issue two reservation requests, right? If so, this would substantially simplify the request structure. And so far, I've not heard of any use case that multiple reservations would not work for transit routing.
??
Jerry
On 3/12/11 10:35 PM, John MacAuley wrote:
Taking Jerry's definition and Tomohiro's note not to use domain or endpoint I have defined the following three XML schema components:
• A "Path Object Type" consists of at a minimum an "aSTP" and a "zSTP", with an optional ordered list of "STP" defining the path through the network. • An "STP Type" consisting of a mandatory "Network Id" string and a mandatory "Local Id" string that uniquely identify the STP. There is an optional "Order" attribute that will only be populated when the STP is part of the ordered list. • An "STP List Type" that will support both an ordered and unordered list of STPs.
So is does my definition of a Path Object cover what was intended in the CS architecture document?
<xsd:complexType name="PathObjectType"> <xsd:sequence> <xsd:element name="aSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> <xsd:element name="orderedStpList" type="tns:StpListType" /> <xsd:element name="zSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="StpType"> <xsd:sequence> <xsd:element name="networkId" type="xsd:string" minOccurs="1" maxOccurs="1" /> <xsd:element name="localId" type="xsd:string" minOccurs="1" maxOccurs="1" /> </xsd:sequence> <xsd:attribute name="order" type="xsd:integer" /> </xsd:complexType>
<xsd:complexType name="StpListType"> <xsd:sequence> <xsd:element name="stp" type="tns:StpType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType>
On 2011-03-12, at 10:11 PM, Jerry Sobieski wrote:
Hi John-
Yes. For NSI I think we can say an STP==endpoint.
I think STPs in the abstract sense may be topological locations other than just a port or a VLAN, but for the purposes of NSI v1.0, I think a "real STP" is indeed a location in the topology where a connection may originate or terminate.
(I note that I used a circular reference in the endpoint definition. Apologies. An Endpoint is the physical topological terminus of a connection.) I do reserve some flexibility in the abstraction however. I think there are ways we can use Service Termination Points to indicate larger complexes of topological elements. If folks are intersted I will elaborate, but for now, and to be expedient with respect to defining ReserveRequest() parameters, I suggest we accept an adequate definition and leave additional refinement to later.
Is this helpful? Jerry
On 3/12/11 9:57 PM, John MacAuley wrote:
Jerry,
So based on your definition below is STP == Endpoint Reference from an NSI protocol perspective?
Definitions:
Service Termination Point := 1. An abstract object that represents the ingress or egress point of a connection, or the abstract notion of a location in a topology where a connection could potentially originate or terminate. 2. A real point in a topology where a connection can originate or terminate.
Endpoint := In NSI, this is a location within a network that can be used as an endpoint for a connection.
Endpoint Reference := a two-tuple consisting of a {<network name>, <endpoint name>} . An “endpoint reference” is this tuple, the “endpoint” itself is the topological location it identifies.
John.
nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Inder Monga imonga@es.net
--- Inder Monga imonga@es.net
The strategy I took in defining the WSDL operations it to return the reserved connection parameters in the reserveConfirmed, and queryResult (Inder I need your slides so I can get the names correct). These are similar to the original reservation parameters, except with the addition of connection state, the chosen guaranteed parameters, the chosen preferred parameters, and optionally the PathObject describing the chosen path (may be removed based on discussions). I believe, with the exception of PathObject, that this would line up with discussions in Hong Kong. As for the hop-by-hop parameters - I have left it up to the NSA implementation to decide what is returned up the tree. I think specifying this is out-of-scope ;-) Seriously now, I visualized that the first Provider NSA would take the sourceSTP and destSTP, perform path computation using some type of topology, then reserve this STP topology down the tree. The resulting reserveConfirmed would contain this STP topology which, at a minimum, would be the inter-domain STP entities interconnecting the domains. John. ----- Original Message -----
From: "Inder Monga" <imonga@es.net> To: "Jerry Sobieski" <jerry@nordu.net> Cc: "John MacAuley" <john.macauley@surfnet.nl>, nsi-wg@ogf.org Sent: Monday, March 14, 2011 12:38:47 PM Subject: Re: [Nsi-wg] Service Termination Points or maybe I am confused, either way -
The PA's state and request parameters as-built - the request parameters as built may have the abstract representation of the various "segments" of the call with any information that may be shared. Is that what I am assuming for "hop by hop" information. but this may not be what Chin/John had been meaning in their responses.
Inder
On Mar 14, 2011, at 9:28 AM, Jerry Sobieski wrote:
Hmm...maybe I am confused... (not often:-)
What hop by hop aspects are we speaking to?
J
On 3/14/11 12:21 PM, Inder Monga wrote:
Returning the hop-by-hop capabilities does not necessarily imply walking the tree.
Inder
On Mar 14, 2011, at 7:50 AM, Jerry Sobieski wrote:
I think we had agreed at GLIF that queries would be (for now) just returning the PA's state and the request parameters as-built. That there was no walking the tree implied at this time...?
J
On 3/13/11 12:29 PM, John MacAuley wrote:
If we remove the hop-by-hop capabilities from the reservation request, do I also remove it from any queries?
On 2011-03-13, at 1:06 PM, Chin Guok wrote:
I'm fine just specifying the source and destination in the initial implementation. However I think that as we evolve the protocol, being able to specify "mid-point" STPs will be useful.
If I recall correctly, the issue was that the end user may not be able to see the "mid-point" STPs and thus is unable to verify the path. However as we start adding other services (i.e. monitoring, etc), lack of visibility may not be an issue.
- Chin
--On March 12, 2011 11:51:20 PM -0500 John MacAuley<john.macauley@surfnet.nl> wrote:
> I am okay not to specify anything other than the source and > destination, > but was this not the whole discussion around not routing > traffic through > certain locations by specifying the route? It resulted in the > trust > discussion. > > > Does anyone else have strong opinions on the topic? > > > John. > > > > > On 2011-03-12, at 11:42 PM, Jerry Sobieski wrote: > > > Hi John- > I know we've had long discussions about path objects. But I am > not so > sure they are necessary... > > If we can make two concatenated connections and treat them as > one, then > why do we need to specify loose hops? > We can instead just issue two reservation requests, right? If > so, this > would substantially simplify the request structure. And so far, > I've not > heard of any use case that multiple reservations would not work > for > transit routing. > > ?? > > Jerry > > > On 3/12/11 10:35 PM, John MacAuley wrote: > > > Taking Jerry's definition and Tomohiro's note not to use domain > or > endpoint I have defined the following three XML schema > components: > > > > • A "Path Object Type" consists of at a minimum an "aSTP" and > a > "zSTP", with an optional ordered list of "STP" defining the > path through > the network. > • An "STP Type" consisting of a mandatory "Network Id" string > and a > mandatory "Local Id" string that uniquely identify the STP. > There is an > optional "Order" attribute that will only be populated when the > STP is > part of the ordered list. > • An "STP List Type" that will support both an ordered and > unordered > list of STPs. > > > > So is does my definition of a Path Object cover what was > intended in the > CS architecture document? > > > <xsd:complexType name="PathObjectType"> > <xsd:sequence> > <xsd:element name="aSTP" type="tns:StpType" > minOccurs="1" > maxOccurs="1" /> > <xsd:element name="orderedStpList" > type="tns:StpListType" /> > <xsd:element name="zSTP" type="tns:StpType" > minOccurs="1" > maxOccurs="1" /> > </xsd:sequence> > </xsd:complexType> > > <xsd:complexType name="StpType"> > <xsd:sequence> > <xsd:element name="networkId" type="xsd:string" > minOccurs="1" > maxOccurs="1" /> > <xsd:element name="localId" type="xsd:string" > minOccurs="1" > maxOccurs="1" /> > </xsd:sequence> > <xsd:attribute name="order" type="xsd:integer" /> > </xsd:complexType> > > <xsd:complexType name="StpListType"> > <xsd:sequence> > <xsd:element name="stp" type="tns:StpType" > minOccurs="0" > maxOccurs="unbounded" /> > </xsd:sequence> > </xsd:complexType> > > > > On 2011-03-12, at 10:11 PM, Jerry Sobieski wrote: > > > Hi John- > > Yes. For NSI I think we can say an STP==endpoint. > > I think STPs in the abstract sense may be topological locations > other > than just a port or a VLAN, but for the purposes of NSI v1.0, I > think a > "real STP" is indeed a location in the topology where a > connection may > originate or terminate. > > (I note that I used a circular reference in the endpoint > definition. > Apologies. An Endpoint is the physical topological terminus of > a > connection.) I do reserve some flexibility in the abstraction > however. I think there are ways we can use Service Termination > Points to > indicate larger complexes of topological elements. If folks are > intersted I will elaborate, but for now, and to be expedient > with respect > to defining ReserveRequest() parameters, I suggest we accept an > adequate > definition and leave additional refinement to later. > > Is this helpful? > Jerry > > On 3/12/11 9:57 PM, John MacAuley wrote: > > Jerry, > > > So based on your definition below is STP == Endpoint Reference > from an > NSI protocol perspective? > > Definitions: > > Service Termination Point := 1. An abstract object that > represents the > ingress or egress point of a connection, or the abstract notion > of a > location in a topology where a connection could potentially > originate or > terminate. 2. A real point in a topology where a connection can > originate or terminate. > > Endpoint := In NSI, this is a location within a network that > can be used > as an endpoint for a connection. > > Endpoint Reference := a two-tuple consisting of a {<network > name>, > <endpoint name>} . An “endpoint reference” is this tuple, the > “endpoint” itself is the topological location it identifies. > > John. > > > > > >
nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Inder Monga imonga@es.net
--- Inder Monga imonga@es.net
Yes, the hop-by-hop info I was referring to was what John mentions below, which at a minimum, is the inter-domain STP entities interconnecting the domains. I foresee that this information can be recursively passed up the tree/chain as the reservation request is returned successfully. I think John's comment about it being optional is fine with me. We cannot enforce a mid-level NSA in a workflow that decides not to return intermediate STP info. - Chin --On March 14, 2011 5:55:34 PM +0100 John MacAuley <john.macauley@surfnet.nl> wrote:
The strategy I took in defining the WSDL operations it to return the reserved connection parameters in the reserveConfirmed, and queryResult (Inder I need your slides so I can get the names correct). These are similar to the original reservation parameters, except with the addition of connection state, the chosen guaranteed parameters, the chosen preferred parameters, and optionally the PathObject describing the chosen path (may be removed based on discussions). I believe, with the exception of PathObject, that this would line up with discussions in Hong Kong.
As for the hop-by-hop parameters - I have left it up to the NSA implementation to decide what is returned up the tree. I think specifying this is out-of-scope ;-)
Seriously now, I visualized that the first Provider NSA would take the sourceSTP and destSTP, perform path computation using some type of topology, then reserve this STP topology down the tree. The resulting reserveConfirmed would contain this STP topology which, at a minimum, would be the inter-domain STP entities interconnecting the domains.
John.
----- Original Message -----
From: "Inder Monga" <imonga@es.net> To: "Jerry Sobieski" <jerry@nordu.net> Cc: "John MacAuley" <john.macauley@surfnet.nl>, nsi-wg@ogf.org Sent: Monday, March 14, 2011 12:38:47 PM Subject: Re: [Nsi-wg] Service Termination Points or maybe I am confused, either way -
The PA's state and request parameters as-built - the request parameters as built may have the abstract representation of the various "segments" of the call with any information that may be shared. Is that what I am assuming for "hop by hop" information. but this may not be what Chin/John had been meaning in their responses.
Inder
On Mar 14, 2011, at 9:28 AM, Jerry Sobieski wrote:
Hmm...maybe I am confused... (not often:-)
What hop by hop aspects are we speaking to?
J
On 3/14/11 12:21 PM, Inder Monga wrote:
Returning the hop-by-hop capabilities does not necessarily imply walking the tree.
Inder
On Mar 14, 2011, at 7:50 AM, Jerry Sobieski wrote:
I think we had agreed at GLIF that queries would be (for now) just returning the PA's state and the request parameters as-built. That there was no walking the tree implied at this time...?
J
On 3/13/11 12:29 PM, John MacAuley wrote:
If we remove the hop-by-hop capabilities from the reservation request, do I also remove it from any queries?
On 2011-03-13, at 1:06 PM, Chin Guok wrote:
> I'm fine just specifying the source and destination in the > initial implementation. However I think that as we evolve the > protocol, being able to specify "mid-point" STPs will be useful. > > If I recall correctly, the issue was that the end user may not > be able to see the "mid-point" STPs and thus is unable to verify > the path. However as we start adding other services (i.e. > monitoring, etc), lack of visibility may not be an issue. > > - Chin > > --On March 12, 2011 11:51:20 PM -0500 John > MacAuley<john.macauley@surfnet.nl> wrote: > >> I am okay not to specify anything other than the source and >> destination, >> but was this not the whole discussion around not routing >> traffic through >> certain locations by specifying the route? It resulted in the >> trust >> discussion. >> >> >> Does anyone else have strong opinions on the topic? >> >> >> John. >> >> >> >> >> On 2011-03-12, at 11:42 PM, Jerry Sobieski wrote: >> >> >> Hi John- >> I know we've had long discussions about path objects. But I am >> not so >> sure they are necessary... >> >> If we can make two concatenated connections and treat them as >> one, then >> why do we need to specify loose hops? >> We can instead just issue two reservation requests, right? If >> so, this >> would substantially simplify the request structure. And so far, >> I've not >> heard of any use case that multiple reservations would not work >> for >> transit routing. >> >> ?? >> >> Jerry >> >> >> On 3/12/11 10:35 PM, John MacAuley wrote: >> >> >> Taking Jerry's definition and Tomohiro's note not to use domain >> or >> endpoint I have defined the following three XML schema >> components: >> >> >> >> • A "Path Object Type" consists of at a minimum an "aSTP" and >> a >> "zSTP", with an optional ordered list of "STP" defining the >> path through >> the network. >> • An "STP Type" consisting of a mandatory "Network Id" string >> and a >> mandatory "Local Id" string that uniquely identify the STP. >> There is an >> optional "Order" attribute that will only be populated when the >> STP is >> part of the ordered list. >> • An "STP List Type" that will support both an ordered and >> unordered >> list of STPs. >> >> >> >> So is does my definition of a Path Object cover what was >> intended in the >> CS architecture document? >> >> >> <xsd:complexType name="PathObjectType"> >> <xsd:sequence> >> <xsd:element name="aSTP" type="tns:StpType" >> minOccurs="1" >> maxOccurs="1" /> >> <xsd:element name="orderedStpList" >> type="tns:StpListType" /> >> <xsd:element name="zSTP" type="tns:StpType" >> minOccurs="1" >> maxOccurs="1" /> >> </xsd:sequence> >> </xsd:complexType> >> >> <xsd:complexType name="StpType"> >> <xsd:sequence> >> <xsd:element name="networkId" type="xsd:string" >> minOccurs="1" >> maxOccurs="1" /> >> <xsd:element name="localId" type="xsd:string" >> minOccurs="1" >> maxOccurs="1" /> >> </xsd:sequence> >> <xsd:attribute name="order" type="xsd:integer" /> >> </xsd:complexType> >> >> <xsd:complexType name="StpListType"> >> <xsd:sequence> >> <xsd:element name="stp" type="tns:StpType" >> minOccurs="0" >> maxOccurs="unbounded" /> >> </xsd:sequence> >> </xsd:complexType> >> >> >> >> On 2011-03-12, at 10:11 PM, Jerry Sobieski wrote: >> >> >> Hi John- >> >> Yes. For NSI I think we can say an STP==endpoint. >> >> I think STPs in the abstract sense may be topological locations >> other >> than just a port or a VLAN, but for the purposes of NSI v1.0, I >> think a >> "real STP" is indeed a location in the topology where a >> connection may >> originate or terminate. >> >> (I note that I used a circular reference in the endpoint >> definition. >> Apologies. An Endpoint is the physical topological terminus of >> a >> connection.) I do reserve some flexibility in the abstraction >> however. I think there are ways we can use Service Termination >> Points to >> indicate larger complexes of topological elements. If folks are >> intersted I will elaborate, but for now, and to be expedient >> with respect >> to defining ReserveRequest() parameters, I suggest we accept an >> adequate >> definition and leave additional refinement to later. >> >> Is this helpful? >> Jerry >> >> On 3/12/11 9:57 PM, John MacAuley wrote: >> >> Jerry, >> >> >> So based on your definition below is STP == Endpoint Reference >> from an >> NSI protocol perspective? >> >> Definitions: >> >> Service Termination Point := 1. An abstract object that >> represents the >> ingress or egress point of a connection, or the abstract notion >> of a >> location in a topology where a connection could potentially >> originate or >> terminate. 2. A real point in a topology where a connection can >> originate or terminate. >> >> Endpoint := In NSI, this is a location within a network that >> can be used >> as an endpoint for a connection. >> >> Endpoint Reference := a two-tuple consisting of a {<network >> name>, >> <endpoint name>} . An “endpoint reference” is this tuple, the >> “endpoint” itself is the topological location it identifies. >> >> John. >> >> >> >> >> >> > >
nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Inder Monga imonga@es.net
--- Inder Monga imonga@es.net
nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
On 3/14/11 2:14 PM, Chin Guok wrote:
Yes, the hop-by-hop info I was referring to was what John mentions below, which at a minimum, is the inter-domain STP entities interconnecting the domains. I foresee that this information can be recursively passed up the tree/chain as the reservation request is returned successfully. I think John's comment about it being optional is fine with me. We cannot enforce a mid-level NSA in a workflow that decides not to return intermediate STP info.
- Chin
--On March 14, 2011 5:55:34 PM +0100 John MacAuley <john.macauley@surfnet.nl> wrote:
The strategy I took in defining the WSDL operations it to return the reserved connection parameters in the reserveConfirmed, and queryResult (Inder I need your slides so I can get the names correct). These are similar to the original reservation parameters, except with the addition of connection state, the chosen guaranteed parameters, the chosen preferred parameters, and optionally the PathObject describing the chosen path (may be removed based on discussions). I believe, with the exception of PathObject, that this would line up with discussions in Hong Kong.
As for the hop-by-hop parameters - I have left it up to the NSA implementation to decide what is returned up the tree. I think specifying this is out-of-scope ;-)
Seriously now, I visualized that the first Provider NSA would take the sourceSTP and destSTP, perform path computation using some type of topology, then reserve this STP topology down the tree. The resulting reserveConfirmed would contain this STP topology which, at a minimum, would be the inter-domain STP entities interconnecting the domains. Hey John - This sounds elegant and the way it ought to work. However, as I state in another post though, the network transport as-built info should IMO have a different security context than user as-built info. Plus we have not agreed on the need that path information must be returned, so this will not work reliably regardless of the elegance.
I think our NSI model of a Connection := "STP A ingress framing" + "Network transport provisioning" + "STP Z egress framing" is an important model to keep in mind... I think that the network transport provisioning represents information that is not part of the service commitment to the user. Ergo, the user is not entitled to it just because its his data transport instance. This information can be had, just not as part of the connection service request... maybe a query is better/more apropriate mechanism with potentially different authorization credentials. But I think in the NSI context, the network must be able to protect all the network stuff for security, privacy, competitive, or other reasons. The user is not entitled to network stuff. In our model, we expect the ReserveConfirm to be the network accepting responsibility for providing a service instance with a certain guarranteed performance. I think we are really missing an important game changing opportunity if we do not hold the network responsible for that commitment. If we delegate responsibility for performance guarantees to the network, then we don't need all this network stuff to debug the service instance...we just need a way to Ding the network when the circuit is underperforming to say "FIX IT!" (:-) Its still not clear to me *why* a user would care about the path their service request takes ... It seems to me most of the compelling reasons we hear (e.g. path diversity, security, or debugging) miss the point: /We have no mechanism for asking for path diversity or policy based routes/, so what are we looking for?? We have no NSI plan or architectural model for fault resolution or performance verification - so asking for NSI path info on that basis is at best premature. There is no guaranty that path information you return will be at all useful. Regardless, I thought we agreed to just return [user] as-built info for a particular CID as the result of a Query in v1.0 This will be simple and nominally useful. I do not recall concensus on returning path information. (FYI all: I am not resisting these features...just resisting trying to get them all into v1.0 n the next week - we need to get this draft out asap. I am more than willing to discuss all of these features as part of v1.1 or v2.... It will be fun. But lets not add anything we haven't thought out completely in the group and have concensus on.) Thanks!! Jerry
John.
----- Original Message -----
From: "Inder Monga"<imonga@es.net> To: "Jerry Sobieski"<jerry@nordu.net> Cc: "John MacAuley"<john.macauley@surfnet.nl>, nsi-wg@ogf.org Sent: Monday, March 14, 2011 12:38:47 PM Subject: Re: [Nsi-wg] Service Termination Points or maybe I am confused, either way -
The PA's state and request parameters as-built - the request parameters as built may have the abstract representation of the various "segments" of the call with any information that may be shared. Is that what I am assuming for "hop by hop" information. but this may not be what Chin/John had been meaning in their responses.
Inder
On Mar 14, 2011, at 9:28 AM, Jerry Sobieski wrote:
Hmm...maybe I am confused... (not often:-)
What hop by hop aspects are we speaking to?
J
On 3/14/11 12:21 PM, Inder Monga wrote:
Returning the hop-by-hop capabilities does not necessarily imply walking the tree.
Inder
On Mar 14, 2011, at 7:50 AM, Jerry Sobieski wrote:
I think we had agreed at GLIF that queries would be (for now) just returning the PA's state and the request parameters as-built. That there was no walking the tree implied at this time...?
J
On 3/13/11 12:29 PM, John MacAuley wrote: > If we remove the hop-by-hop capabilities from the reservation > request, do I also remove it from any queries? > > On 2011-03-13, at 1:06 PM, Chin Guok wrote: > >> I'm fine just specifying the source and destination in the >> initial implementation. However I think that as we evolve the >> protocol, being able to specify "mid-point" STPs will be useful. >> >> If I recall correctly, the issue was that the end user may not >> be able to see the "mid-point" STPs and thus is unable to verify >> the path. However as we start adding other services (i.e. >> monitoring, etc), lack of visibility may not be an issue. >> >> - Chin >> >> --On March 12, 2011 11:51:20 PM -0500 John >> MacAuley<john.macauley@surfnet.nl> wrote: >> >>> I am okay not to specify anything other than the source and >>> destination, >>> but was this not the whole discussion around not routing >>> traffic through >>> certain locations by specifying the route? It resulted in the >>> trust >>> discussion. >>> >>> >>> Does anyone else have strong opinions on the topic? >>> >>> >>> John. >>> >>> >>> >>> >>> On 2011-03-12, at 11:42 PM, Jerry Sobieski wrote: >>> >>> >>> Hi John- >>> I know we've had long discussions about path objects. But I am >>> not so >>> sure they are necessary... >>> >>> If we can make two concatenated connections and treat them as >>> one, then >>> why do we need to specify loose hops? >>> We can instead just issue two reservation requests, right? If >>> so, this >>> would substantially simplify the request structure. And so far, >>> I've not >>> heard of any use case that multiple reservations would not work >>> for >>> transit routing. >>> >>> ?? >>> >>> Jerry >>> >>> >>> On 3/12/11 10:35 PM, John MacAuley wrote: >>> >>> >>> Taking Jerry's definition and Tomohiro's note not to use domain >>> or >>> endpoint I have defined the following three XML schema >>> components: >>> >>> >>> >>> • A "Path Object Type" consists of at a minimum an "aSTP" and >>> a >>> "zSTP", with an optional ordered list of "STP" defining the >>> path through >>> the network. >>> • An "STP Type" consisting of a mandatory "Network Id" string >>> and a >>> mandatory "Local Id" string that uniquely identify the STP. >>> There is an >>> optional "Order" attribute that will only be populated when the >>> STP is >>> part of the ordered list. >>> • An "STP List Type" that will support both an ordered and >>> unordered >>> list of STPs. >>> >>> >>> >>> So is does my definition of a Path Object cover what was >>> intended in the >>> CS architecture document? >>> >>> >>> <xsd:complexType name="PathObjectType"> >>> <xsd:sequence> >>> <xsd:element name="aSTP" type="tns:StpType" >>> minOccurs="1" >>> maxOccurs="1" /> >>> <xsd:element name="orderedStpList" >>> type="tns:StpListType" /> >>> <xsd:element name="zSTP" type="tns:StpType" >>> minOccurs="1" >>> maxOccurs="1" /> >>> </xsd:sequence> >>> </xsd:complexType> >>> >>> <xsd:complexType name="StpType"> >>> <xsd:sequence> >>> <xsd:element name="networkId" type="xsd:string" >>> minOccurs="1" >>> maxOccurs="1" /> >>> <xsd:element name="localId" type="xsd:string" >>> minOccurs="1" >>> maxOccurs="1" /> >>> </xsd:sequence> >>> <xsd:attribute name="order" type="xsd:integer" /> >>> </xsd:complexType> >>> >>> <xsd:complexType name="StpListType"> >>> <xsd:sequence> >>> <xsd:element name="stp" type="tns:StpType" >>> minOccurs="0" >>> maxOccurs="unbounded" /> >>> </xsd:sequence> >>> </xsd:complexType> >>> >>> >>> >>> On 2011-03-12, at 10:11 PM, Jerry Sobieski wrote: >>> >>> >>> Hi John- >>> >>> Yes. For NSI I think we can say an STP==endpoint. >>> >>> I think STPs in the abstract sense may be topological locations >>> other >>> than just a port or a VLAN, but for the purposes of NSI v1.0, I >>> think a >>> "real STP" is indeed a location in the topology where a >>> connection may >>> originate or terminate. >>> >>> (I note that I used a circular reference in the endpoint >>> definition. >>> Apologies. An Endpoint is the physical topological terminus of >>> a >>> connection.) I do reserve some flexibility in the abstraction >>> however. I think there are ways we can use Service Termination >>> Points to >>> indicate larger complexes of topological elements. If folks are >>> intersted I will elaborate, but for now, and to be expedient >>> with respect >>> to defining ReserveRequest() parameters, I suggest we accept an >>> adequate >>> definition and leave additional refinement to later. >>> >>> Is this helpful? >>> Jerry >>> >>> On 3/12/11 9:57 PM, John MacAuley wrote: >>> >>> Jerry, >>> >>> >>> So based on your definition below is STP == Endpoint Reference >>> from an >>> NSI protocol perspective? >>> >>> Definitions: >>> >>> Service Termination Point := 1. An abstract object that >>> represents the >>> ingress or egress point of a connection, or the abstract notion >>> of a >>> location in a topology where a connection could potentially >>> originate or >>> terminate. 2. A real point in a topology where a connection can >>> originate or terminate. >>> >>> Endpoint := In NSI, this is a location within a network that >>> can be used >>> as an endpoint for a connection. >>> >>> Endpoint Reference := a two-tuple consisting of a {<network >>> name>, >>> <endpoint name>} . An “endpoint reference” is this tuple, the >>> “endpoint” itself is the topological location it identifies. >>> >>> John. >>> >>> >>> >>> >>> >>> >> _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Inder Monga imonga@es.net
Inder Monga imonga@es.net
nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Okay, sounds good. I have it in the WSDL now, but it is easy enough to remove.
I think we had agreed at GLIF that queries would be (for now) just returning the PA's state and the request parameters as-built. That there was no walking the tree implied at this time...?
J
Well to address Inder's thoughts about having the segmentation returned... I do seem to recall that we decided to shelve "special" queries until we had more time to talk through the use cases and appropriate service models and semantics. A "normal" Query would return the PA's local state for the reservation, and the as-built as far as the user's requested reservation parameters are concerned including defaulted parameters as appropriate. (I don't recall any "prefered" paramaters...) The normal as built information would be the summary of what the PA committed to deliver to the RA (for instance the summary Frame Loss Rate, or the summary latency, or summary MTU.) But nothing beyond that. This is the "user stuff". Since the PA segmentation is solely an internal policy decision of the PA, and actually constitute independent connection requests of the local NSA, this could be considered internal information not privy to the parent RA, at least not under the same authorization as the service request itself. Ie. the PA must be allowed to authorize all the internal network transport segmentation information separately. Thats "network stuff". Not the same s "user stuff" :-) Further, the local NSA may not even use the same authorization credentials or service parametrs for the children as the parent. So that even if the NSA returned the segmentation to the parent, there is no guaranty that the parent will be able to query the respective segment PAs for their information. And I am sure all networks will love divulging their authorization credentials to external agents (:-) If thats not enough to convince you of the futility of it all, there is nothing to stop the local NSA from virtualizing the connection - I.e. building a tunnel directly to the destination network through 25 transit networks, installing that path in its topology DB, and then using a single segment for the actual request from here to there. Then it all gets hidden from the query anyway because the tunnel was not part of the request segmentation. To be clear, it *can* work - all we need to do is to think through the query processes and the authorization requirements, and the primitive parameter set(s). But there is a lot to discuss even for such a simple seeming request. Can we shelve the "special" query until V2? J On 3/14/11 12:40 PM, John MacAuley wrote:
Okay, sounds good. I have it in the WSDL now, but it is easy enough to remove.
I think we had agreed at GLIF that queries would be (for now) just returning the PA's state and the request parameters as-built. That there was no walking the tree implied at this time...?
J
As for hop by hop for reservations....a loose hop path object is only required when hop-by-hop is the *only* mechansim for reserving a connection and the request must originate at the source. When third party requests (tree option) are supported (.e. NSI:-) you simply segment what would have been a loose hop path object and issue the corresponding A>B and B>C segments separately. Ergo, no loose hop PO are necessary. J On 3/13/11 12:29 PM, John MacAuley wrote:
If we remove the hop-by-hop capabilities from the reservation request, do I also remove it from any queries?
On 2011-03-13, at 1:06 PM, Chin Guok wrote:
I'm fine just specifying the source and destination in the initial implementation. However I think that as we evolve the protocol, being able to specify "mid-point" STPs will be useful.
If I recall correctly, the issue was that the end user may not be able to see the "mid-point" STPs and thus is unable to verify the path. However as we start adding other services (i.e. monitoring, etc), lack of visibility may not be an issue.
- Chin
--On March 12, 2011 11:51:20 PM -0500 John MacAuley<john.macauley@surfnet.nl> wrote:
I am okay not to specify anything other than the source and destination, but was this not the whole discussion around not routing traffic through certain locations by specifying the route? It resulted in the trust discussion.
Does anyone else have strong opinions on the topic?
John.
On 2011-03-12, at 11:42 PM, Jerry Sobieski wrote:
Hi John- I know we've had long discussions about path objects. But I am not so sure they are necessary...
If we can make two concatenated connections and treat them as one, then why do we need to specify loose hops? We can instead just issue two reservation requests, right? If so, this would substantially simplify the request structure. And so far, I've not heard of any use case that multiple reservations would not work for transit routing.
??
Jerry
On 3/12/11 10:35 PM, John MacAuley wrote:
Taking Jerry's definition and Tomohiro's note not to use domain or endpoint I have defined the following three XML schema components:
• A "Path Object Type" consists of at a minimum an "aSTP" and a "zSTP", with an optional ordered list of "STP" defining the path through the network. • An "STP Type" consisting of a mandatory "Network Id" string and a mandatory "Local Id" string that uniquely identify the STP. There is an optional "Order" attribute that will only be populated when the STP is part of the ordered list. • An "STP List Type" that will support both an ordered and unordered list of STPs.
So is does my definition of a Path Object cover what was intended in the CS architecture document?
<xsd:complexType name="PathObjectType"> <xsd:sequence> <xsd:element name="aSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> <xsd:element name="orderedStpList" type="tns:StpListType" /> <xsd:element name="zSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="StpType"> <xsd:sequence> <xsd:element name="networkId" type="xsd:string" minOccurs="1" maxOccurs="1" /> <xsd:element name="localId" type="xsd:string" minOccurs="1" maxOccurs="1" /> </xsd:sequence> <xsd:attribute name="order" type="xsd:integer" /> </xsd:complexType>
<xsd:complexType name="StpListType"> <xsd:sequence> <xsd:element name="stp" type="tns:StpType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType>
On 2011-03-12, at 10:11 PM, Jerry Sobieski wrote:
Hi John-
Yes. For NSI I think we can say an STP==endpoint.
I think STPs in the abstract sense may be topological locations other than just a port or a VLAN, but for the purposes of NSI v1.0, I think a "real STP" is indeed a location in the topology where a connection may originate or terminate.
(I note that I used a circular reference in the endpoint definition. Apologies. An Endpoint is the physical topological terminus of a connection.) I do reserve some flexibility in the abstraction however. I think there are ways we can use Service Termination Points to indicate larger complexes of topological elements. If folks are intersted I will elaborate, but for now, and to be expedient with respect to defining ReserveRequest() parameters, I suggest we accept an adequate definition and leave additional refinement to later.
Is this helpful? Jerry
On 3/12/11 9:57 PM, John MacAuley wrote:
Jerry,
So based on your definition below is STP == Endpoint Reference from an NSI protocol perspective?
Definitions:
Service Termination Point := 1. An abstract object that represents the ingress or egress point of a connection, or the abstract notion of a location in a topology where a connection could potentially originate or terminate. 2. A real point in a topology where a connection can originate or terminate.
Endpoint := In NSI, this is a location within a network that can be used as an endpoint for a connection.
Endpoint Reference := a two-tuple consisting of a {<network name>, <endpoint name>} . An “endpoint reference” is this tuple, the “endpoint” itself is the topological location it identifies.
John.
On 3/13/11 1:06 PM, Chin Guok wrote:
I'm fine just specifying the source and destination in the initial implementation. However I think that as we evolve the protocol, being able to specify "mid-point" STPs will be useful.
I think pushing it to post-v1 discussion will be best. I do think it merits serious discussion.
If I recall correctly, the issue was that the end user may not be able to see the "mid-point" STPs and thus is unable to verify the path. However as we start adding other services (i.e. monitoring, etc), lack of visibility may not be an issue. Exactly my point. We have a LOT more work before NSI is a full set of functionality. Lets not boil the ocean in the next two weeks.
THe verification was part of it. But fundamentally if A>B>C is equivalent to A>B + B>C, why do we need both? Its needless complexity. J
- Chin
--On March 12, 2011 11:51:20 PM -0500 John MacAuley <john.macauley@surfnet.nl> wrote:
I am okay not to specify anything other than the source and destination, but was this not the whole discussion around not routing traffic through certain locations by specifying the route? It resulted in the trust discussion.
Does anyone else have strong opinions on the topic?
John.
On 2011-03-12, at 11:42 PM, Jerry Sobieski wrote:
Hi John- I know we've had long discussions about path objects. But I am not so sure they are necessary...
If we can make two concatenated connections and treat them as one, then why do we need to specify loose hops? We can instead just issue two reservation requests, right? If so, this would substantially simplify the request structure. And so far, I've not heard of any use case that multiple reservations would not work for transit routing.
??
Jerry
On 3/12/11 10:35 PM, John MacAuley wrote:
Taking Jerry's definition and Tomohiro's note not to use domain or endpoint I have defined the following three XML schema components:
• A "Path Object Type" consists of at a minimum an "aSTP" and a "zSTP", with an optional ordered list of "STP" defining the path through the network. • An "STP Type" consisting of a mandatory "Network Id" string and a mandatory "Local Id" string that uniquely identify the STP. There is an optional "Order" attribute that will only be populated when the STP is part of the ordered list. • An "STP List Type" that will support both an ordered and unordered list of STPs.
So is does my definition of a Path Object cover what was intended in the CS architecture document?
<xsd:complexType name="PathObjectType"> <xsd:sequence> <xsd:element name="aSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> <xsd:element name="orderedStpList" type="tns:StpListType" /> <xsd:element name="zSTP" type="tns:StpType" minOccurs="1" maxOccurs="1" /> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="StpType"> <xsd:sequence> <xsd:element name="networkId" type="xsd:string" minOccurs="1" maxOccurs="1" /> <xsd:element name="localId" type="xsd:string" minOccurs="1" maxOccurs="1" /> </xsd:sequence> <xsd:attribute name="order" type="xsd:integer" /> </xsd:complexType>
<xsd:complexType name="StpListType"> <xsd:sequence> <xsd:element name="stp" type="tns:StpType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType>
On 2011-03-12, at 10:11 PM, Jerry Sobieski wrote:
Hi John-
Yes. For NSI I think we can say an STP==endpoint.
I think STPs in the abstract sense may be topological locations other than just a port or a VLAN, but for the purposes of NSI v1.0, I think a "real STP" is indeed a location in the topology where a connection may originate or terminate.
(I note that I used a circular reference in the endpoint definition. Apologies. An Endpoint is the physical topological terminus of a connection.) I do reserve some flexibility in the abstraction however. I think there are ways we can use Service Termination Points to indicate larger complexes of topological elements. If folks are intersted I will elaborate, but for now, and to be expedient with respect to defining ReserveRequest() parameters, I suggest we accept an adequate definition and leave additional refinement to later.
Is this helpful? Jerry
On 3/12/11 9:57 PM, John MacAuley wrote:
Jerry,
So based on your definition below is STP == Endpoint Reference from an NSI protocol perspective?
Definitions:
Service Termination Point := 1. An abstract object that represents the ingress or egress point of a connection, or the abstract notion of a location in a topology where a connection could potentially originate or terminate. 2. A real point in a topology where a connection can originate or terminate.
Endpoint := In NSI, this is a location within a network that can be used as an endpoint for a connection.
Endpoint Reference := a two-tuple consisting of a {<network name>, <endpoint name>} . An “endpoint reference” is this tuple, the “endpoint” itself is the topological location it identifies.
John.
On 10/03/2011 17:48, Evangelos Chaniotakis wrote:
Jerry,
If I may distill your email to:
"Let's define an NSI-CS endpoint reference as this tuple: (globally unique domain identifier, locally scoped opaque identifier)."
I'm fine with that definition.
The actual implementation/representation/format of such a tuple should be left to the implementors of the protocol. It's just an ordered pair of strings, it does not deserve a big discussion about formats.
GLIF has indeed adopted a simple scheme using a "urn:ogf:network:<domain-name>:<local-part>" identifier. There are some procedures setup to define who creates these things, et cetera. You could argue that the urn:ogf:network part is superfluous, in the end you just need a string that is a globally unique identifier for the connection, or in this case the endpoints. My case for using URNs is that they make it immediately clear what kind of thing you are identifying. They signal to the reader what kind of format the rest of the identifier is going to be, and the reader is also pretty sure that the sender intended it to be like this too. Also, when using URNs you avoid all kinds of nasty confusing things like the allowed characters, encoding, syntax, comparison et cetera. Saying that strings are just simple strings is hopelessly naive in this day and age. Note that NSI does not have to limit itself to urn:ogf:network, this is a prefix that NML has requested in order to identify things. If the NSI wants, it can make the case to get another urn:ogf:<something> prefix. Jeroen.
On Mar 11, 2011, at 4:05 AM, Jeroen van der Ham wrote:
Note that NSI does not have to limit itself to urn:ogf:network, this is a prefix that NML has requested in order to identify things. If the NSI wants, it can make the case to get another urn:ogf:<something> prefix.
Please no. I understand wanting to do something different if there is a reason. But, lets attempt to keep things the same where we can please? Some of us are attempting to support software that already uses some of these constructs. Yes, we can make all kinds of arguments of it being a simple string substitution, but I'd rather spend our programmers time on other things. (That sentiment really stands for this whole discussion.) thanks, jeff
On 2011-03-10, at 11:16 AM, Jerry Sobieski wrote:
If someone thinks we need a URN specification for version 1.0, please pipe up and provide the reasoning - there may be such, I just am unaware of one in my mind at this moment. (But please don't tell me its needed for web services-WS is not why we created NSI:-). Adding a URN prefix qualifies the namespace - why does/should NSI need a qualified namespace for endpoint references? If you think we do, or even if you think it is just a good idea, please explain how this reconciles with the NSI architecture - i.e. how the URN version maps the <network><endpoint> tuple, and how it improves the basic GID mentioned above? Remember, we are only speaking to NSI endpoint references,...
Jerry, It makes me giggle just imagining you in front of our computer having a seizure every time you think of web services. Just to make sure we are clear on definitions, URNs are not specifically associated with web services, and in fact, have little to do with web services. Here is the introduction from RFC2141 that defines the URN: Uniform Resource Names (URNs) are intended to serve as persistent location-independent, resource identifiers and are designed to make it easy to map other namespaces (which share the properties of URNs) into URN-space. Therefore, the URN syntax provides a means to encode character data in a form that can be sent in existing protocols, transcribed on most keyboards, etc. By definition it is exactly what you have been asking for with physical location independent naming. Whether you are using web services or some other binary protocol, a URN is just a syntax for identification and naming. This mechanism has been chosen for use by the GLIF, perfSONAR, and the NML group. Now, a URN also qualifies as an instance of a URI similar to how a URL is also an instance of a URI. Perhaps this is why you may have confused it with web services? Personally, I do not like to be wishy washy with types when defining protocols. Stating that an endpoint mush be from a URN namespace, or more specifically, the OGF URN namespace, will give more clarity in the protocol definition, and bind the protocol definition to other OGF specifications. I would probably define a compound type as follows (I use XML schema since I know it well): <xsd:complexType name="StpType"> <xsd:sequence> <xsd:element name="domain" type="xsd:anyURI" /> <xsd:element name="endpoint" type="xsd:anyURI" /> </xsd:sequence> </xsd:complexType> However, I am not going to argue is people think it should be two strings instead of two URN. John.
Hi all and John :-) - I don't have an aversion to XML - I actually sorta like it due to its structured high level specifications. And even namespaces are not so bad - if they are well considered. But you must admit defining where XML ends and Web Service begin is a slippery slope :-) The problem at hand is thus: How do we identify service "endpoints" or STPs within the NSI context? If we look at some high successful aspects of the internet we see: Names that map to IP addresses, IP addresses that map globally to an interface, and interface addresses that can be moved locally to other hardware without changing references to those interfaces. The <network>:<endpoint> tuple is analogous to the global IP address with its <network>/<host> definition. So we can call the NSI tuple a symbolic global addressing scheme. I think this is an important feature for NSI. AS it turns out, this tuple is sufficient to route a request across the global NSI topology, but is independent of the physical topology. It is the leaf NSA's job to know how to translate an NSI EPR to the local NRM. Indeed, since the leaf NSA is just a PA frontend to the NRM, we can say that translating from NSI EPR to local NRM is the job of the NRM-PA. THis makes the translation to local topology a function of the NRM and out of scope for NSI. We could allow a topological specification as well. But this has the drawback that every application globally referencing that end point will need to know the topological location. If that physical location changes for any reason, all applications need to be changed. Just as IP address *can* be used for URLs, DNS names are used in order to abstract the desired endpoint from the physical location it occupies at the moment. In addition, advertising endpoints by their topological specification allows internal topology to leak out globally. I know Inder (and probably Tomohiro) have questions about how you select VLANs at a remote endpoint, but I view this as a pathfinding issue within each domain - not a global issue. While this is related to topology and visibility, if we stay within the confines/context of the NSI-CS protcol I do not think we need to address this in the standard. At least not immediately. So whether we use a "urn:blah <domain>:<endpoint>" or just a raw tuple "//<domainname>/<endpointname>" is not a big issue with me. As long as we support the tuple and agree on *one* convention that all NSAs must recognize. I have a couple other comments below... On 3/12/11 8:42 PM, John MacAuley wrote:
On 2011-03-10, at 11:16 AM, Jerry Sobieski wrote:
If someone thinks we need a URN specification for version 1.0, please pipe up and provide the reasoning - there may be such, I just am unaware of one in my mind at this moment. (But please don't tell me its needed for web services-WS is not why we created NSI:-). Adding a URN prefix qualifies the namespace - why does/should NSI need a qualified namespace for endpoint references? If you think we do, or even if you think it is just a good idea, please explain how this reconciles with the NSI architecture - i.e. how the URN version maps the <network><endpoint> tuple, and how it improves the basic GID mentioned above? Remember, we are only speaking to _/NSI/_ endpoint references,...
Jerry,
It makes me giggle just imagining you in front of our computer having a seizure every time you think of web services. Well I'm glad I entertain you all:-)
Just to make sure we are clear on definitions, URNs are not specifically associated with web services, and in fact, have little to do with web services. Here is the introduction from RFC2141 that defines the URN:
* Uniform Resource Names (URNs) are intended to serve as persistent location-independent, resource identifiers and are designed to make it easy to map other namespaces (which share the properties of URNs) into URN-space. Therefore, the URN syntax provides a means to encode character data in a form that can be sent in existing protocols, transcribed on most keyboards, etc.
By definition it is exactly what you have been asking for with physical location independent naming. Whether you are using web services or some other binary protocol, a URN is just a syntax for identification and naming. This mechanism has been chosen for use by the GLIF, perfSONAR, and the NML group.
Now, a URN also qualifies as an instance of a URI similar to how a URL is also an instance of a URI. Perhaps this is why you may have confused it with web services? I think my concern is that the endpoints we are trying to reference are not values passed to application services - they are endpoints of conenctions. Is it apropriate to force all users of NSI to adopt OGF naming conventions for their network endpoints? It is one thing to say NSI uses these namepsaces internal to the protocol, its is another to say all users of NSI services must also use OGF name spaces to name
I am truly sorry we have such differing opinions on this. But I have not seen much compelling to change my opinion that Web Services is highly structured to very little practical effect. A noble vision, but it got buried in a mountain of software and specifications. Where is the K&R and Hello World of web services? their endpoints. If we specify any namesapce, it seems to me we are also excluding all others. Is this necessary to identify endpoints suitably?- or just a habit we've gotten into?
Personally, I do not like to be wishy washy with types when defining protocols. Stating that an endpoint mush be from a URN namespace, or more specifically, the OGF URN namespace, will give more clarity in the protocol definition, and bind the protocol definition to other OGF specifications.
Speaking of clarity, how much "clarity" does it really need? What is not clear? We are talking about a two part tuple... That carries no NSI relevant information in the names. Why would more namespaces provide more "clarity"? Namespaces just qualify the ...uh..namespace. duh. I think what you want is not just namespaces but XML schemas. Remember - these names are not places we are sending HTTP commands - these are dataplane end points. Putting all that clarity on them sure seems to me to be unnecessary ...I don't see the confusion.
I would probably define a compound type as follows (I use XML schema since I know it well):
<xsd:complexTypename="StpType"> <xsd:sequence> <xsd:elementname="domain"type="xsd:anyURI"/> <xsd:elementname="endpoint"type="xsd:anyURI"/> </xsd:sequence> </xsd:complexType>
However, I am not going to argue is people think it should be two strings instead of two URN.
John.
Thanks John and all of you for the thoughtful discussion. Jerry
Jerry, I am going to jump in with some questions to better my understanding - embedded below
If we look at some high successful aspects of the internet we see: Names that map to IP addresses, IP addresses that map globally to an interface, and interface addresses that can be moved locally to other hardware without changing references to those interfaces.
The <network>:<endpoint> tuple is analogous to the global IP address with its <network>/<host> definition. So we can call the NSI tuple a symbolic global addressing scheme. I think this is an important feature for NSI. AS it turns out, this tuple is sufficient to route a request across the global NSI topology, but is independent of the physical topology. It is the leaf NSA's job to know how to translate an NSI EPR to the local NRM. Indeed, since the leaf NSA is just a PA frontend to the NRM, we can say that translating from NSI EPR to local NRM is the job of the NRM-PA. THis makes the translation to local topology a function of the NRM and out of scope for NSI.
Please do not use EPR as a sub for STPs - it is already a standardized term..could cause confusion. http://en.wikipedia.org/wiki/WS- Addressing :)
We could allow a topological specification as well. But this has the drawback that every application globally referencing that end point will need to know the topological location. If that physical location changes for any reason, all applications need to be changed. Just as IP address *can* be used for URLs, DNS names are used in order to abstract the desired endpoint from the physical location it occupies at the moment. In addition, advertising endpoints by their topological specification allows internal topology to leak out globally.
I understand what you are saying - but to me what you are suggesting falls within best practices and you cannot mandate someone not to encode topological spec into their local string. for example 3 te-1-4-ur03.santaclara.ca.sfba.comcast.net (68.86.248.17) 17.047 ms 18.316 ms 33.941 ms 4 te-1-10-0-5-ar01.sfsutro.ca.sfba.comcast.net (68.85.155.58) 62.206 ms 72.866 ms 52.751 ms 5 pos-1-7-0-0-cr01.sanjose.ca.ibone.comcast.net (68.86.90.153) 52.351 ms 72.093 ms 32.664 ms 6 pos-0-0-0-0-pe01.529bryant.ca.ibone.comcast.net I just want to be sure you are not referring to encoding like the above which can be done?
I know Inder (and probably Tomohiro) have questions about how you select VLANs at a remote endpoint,
The question is how to specify aggregate end-points using this method of uninterpretable local strings. The number of these end-points when you consider virtual ones can be huge. So there is a benefit in having a specification that can aggregate those. The other question is how to show interconnectivity between two STPs - one in each domain.
but I view this as a pathfinding issue within each domain - not a global issue. While this is related to topology and visibility, if we stay within the confines/context of the NSI-CS protcol I do not think we need to address this in the standard. At least not immediately.
So whether we use a "urn:blah <domain>:<endpoint>" or just a raw tuple "//<domainname>/<endpointname>" is not a big issue with me. As long as we support the tuple and agree on *one* convention that all NSAs must recognize.
I prefer the urn representation (even though we could define our own string delimiter and format) and I imagine that OGF urn will be registered with IANA (http://tools.ietf.org/html/draft-dijkstra-urn-ogf-01 and http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xml) Inder
Just to make sure we are clear on definitions, URNs are not specifically associated with web services, and in fact, have little to do with web services. Here is the introduction from RFC2141 that defines the URN:
Uniform Resource Names (URNs) are intended to serve as persistent location-independent, resource identifiers and are designed to make it easy to map other namespaces (which share the properties of URNs) into URN-space. Therefore, the URN syntax provides a means to encode character data in a form that can be sent in existing protocols, transcribed on most keyboards, etc.
By definition it is exactly what you have been asking for with physical location independent naming. Whether you are using web services or some other binary protocol, a URN is just a syntax for identification and naming. This mechanism has been chosen for use by the GLIF, perfSONAR, and the NML group.
Now, a URN also qualifies as an instance of a URI similar to how a URL is also an instance of a URI. Perhaps this is why you may have confused it with web services? I think my concern is that the endpoints we are trying to reference are not values passed to application services - they are endpoints of conenctions. Is it apropriate to force all users of NSI to adopt OGF naming conventions for their network endpoints? It is one thing to say NSI uses these namepsaces internal to the protocol, its is another to say all users of NSI services must also use OGF name spaces to name their endpoints. If we specify any namesapce, it seems to me we are also excluding all others. Is this necessary to identify endpoints suitably?- or just a habit we've gotten into?
Personally, I do not like to be wishy washy with types when defining protocols. Stating that an endpoint mush be from a URN namespace, or more specifically, the OGF URN namespace, will give more clarity in the protocol definition, and bind the protocol definition to other OGF specifications. Speaking of clarity, how much "clarity" does it really need? What is not clear? We are talking about a two part tuple... That carries no NSI relevant information in the names. Why would more namespaces provide more "clarity"? Namespaces just qualify the ...uh..namespace. duh. I think what you want is not just namespaces but XML schemas.
Remember - these names are not places we are sending HTTP commands - these are dataplane end points. Putting all that clarity on them sure seems to me to be unnecessary ...I don't see the confusion.
I would probably define a compound type as follows (I use XML schema since I know it well):
<xsd:complexType name="StpType"> <xsd:sequence> <xsd:element name="domain" type="xsd:anyURI" /> <xsd:element name="endpoint" type="xsd:anyURI" /> </xsd:sequence> </xsd:complexType>
However, I am not going to argue is people think it should be two strings instead of two URN.
John.
Thanks John and all of you for the thoughtful discussion. Jerry _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
I just want to make sure you do not think I believe we need globally unique endpoint names based on a common URN scheme. This is not the case. When part of Nortel I developed two separate adjacency discovery mechanisms to drive topology discovery. These used mechanisms similar to what Jerry is proposing. The first transmitted adjacency strings in the IS-IS Hello message of the form "AD_2_00:21:e1:d6:d6:70_001_000_012_000_001_ME_1", where the component was the AD version string format (AD_2), the IEEE system id of the network element transmitting the tag (00:21:e1:d6:d6:70), and the encoded port identifier within the shelf (001_000_012_000_001_ME_1). The transmit and receive strings from each network element were then correlated by and external system to match port pairs together. For ASON, where there was a requirement for peer controller discovery, I modified the mechanism to utilize PPP or LAPD unacknowledged unnumbered information frames over SDCC/LDCC and sent an XML formatted string containing the IP address of the managing ASON controller, MAC address of the containing network elements, and the port identifier. This was standardized in ITU-T G.7714.1/Y.1705.1. In both cases, the information passed is similar in concept to what Jerry is proposing, just a different scope of uniqueness. On 2011-03-13, at 1:43 AM, Inder Monga wrote:
I think my concern is that the endpoints we are trying to reference are not values passed to application services - they are endpoints of conenctions. Is it apropriate to force all users of NSI to adopt OGF naming conventions for their network endpoints? It is one thing to say NSI uses these namepsaces internal to the protocol, its is another to say all users of NSI services must also use OGF name spaces to name their endpoints. If we specify any namesapce, it seems to me we are also excluding all others. Is this necessary to identify endpoints suitably?- or just a habit we've gotten into?
The reason I have been assuming this would be true is due to perfSONAR and Fenius, where participants named their endpoints using the OGF URN scheme for consistency and uniqueness globally. Obviously, global uniqueness of each field is not required when put in the context of another field. It is the 20 years experience of knowing how nice it would be for a unified naming scheme that is getting in the way :-)
Speaking of clarity, how much "clarity" does it really need? What is not clear? We are talking about a two part tuple... That carries no NSI relevant information in the names. Why would more namespaces provide more "clarity"? Namespaces just qualify the ...uh..namespace. duh. I think what you want is not just namespaces but XML schemas.
Hmmm... I guess what is not clear to me is the operationalization of this NSI protocol in the current state. We are leaving a considerable amount as "out-of-scope" and many of the types are defined as strings and nondescript attribute lists. I think we will end up doing most of the functional usefulness and interoperability work pairwise between two peering NSA, similar to the exercise I went through with Vangelis when building the Fenius agent on top of OpenDRAC. I am fine with this approach, and perhaps I will get a more certain feeling as we proceed with the reference implementation. John.
Let me apologize for a flipant late night post.... Sorry John - I got a little off track and a bit scappy - sorry. You have good thoughts on these things...had we been in person you would have seen me smiling more:-) Best regards Jerry On 3/13/11 12:27 PM, John MacAuley wrote:
I just want to make sure you do not think I believe we need globally unique endpoint names based on a common URN scheme. This is not the case.
When part of Nortel I developed two separate adjacency discovery mechanisms to drive topology discovery. These used mechanisms similar to what Jerry is proposing. The first transmitted adjacency strings in the IS-IS Hello message of the form "AD_2_00:21:e1:d6:d6:70_001_000_012_000_001_ME_1", where the component was the AD version string format (AD_2), the IEEE system id of the network element transmitting the tag (00:21:e1:d6:d6:70), and the encoded port identifier within the shelf (001_000_012_000_001_ME_1). The transmit and receive strings from each network element were then correlated by and external system to match port pairs together.
For ASON, where there was a requirement for peer controller discovery, I modified the mechanism to utilize PPP or LAPD unacknowledged unnumbered information frames over SDCC/LDCC and sent an XML formatted string containing the IP address of the managing ASON controller, MAC address of the containing network elements, and the port identifier. This was standardized in ITU-T G.7714.1/Y.1705.1.
In both cases, the information passed is similar in concept to what Jerry is proposing, just a different scope of uniqueness.
On 2011-03-13, at 1:43 AM, Inder Monga wrote:
I think my concern is that the endpoints we are trying to reference are not values passed to application services - they are endpoints of conenctions. Is it apropriate to force all users of NSI to adopt OGF naming conventions for their network endpoints? It is one thing to say NSI uses these namepsaces internal to the protocol, its is another to say all users of NSI services must also use OGF name spaces to name their endpoints. If we specify any namesapce, it seems to me we are also excluding all others. Is this necessary to identify endpoints suitably?- or just a habit we've gotten into? The reason I have been assuming this would be true is due to perfSONAR and Fenius, where participants named their endpoints using the OGF URN scheme for consistency and uniqueness globally. Obviously, global uniqueness of each field is not required when put in the context of another field. It is the 20 years experience of knowing how nice it would be for a unified naming scheme that is getting in the way :-)
Speaking of clarity, how much "clarity" does it really need? What is not clear? We are talking about a two part tuple... That carries no NSI relevant information in the names. Why would more namespaces provide more "clarity"? Namespaces just qualify the ...uh..namespace. duh. I think what you want is not just namespaces but XML schemas. Hmmm... I guess what is not clear to me is the operationalization of this NSI protocol in the current state. We are leaving a considerable amount as "out-of-scope" and many of the types are defined as strings and nondescript attribute lists. I think we will end up doing most of the functional usefulness and interoperability work pairwise between two peering NSA, similar to the exercise I went through with Vangelis when building the Fenius agent on top of OpenDRAC. I am fine with this approach, and perhaps I will get a more certain feeling as we proceed with the reference implementation.
John.
No apologies needed. I didn't think you were being flippant and have not taken offence to anything yet. I have learned to call someone if I think i may be misinterpreting something. To me honest, I misread all the reply-to indents and thought Inder was asking the questions. It wasn't until your apology that I realized it was you :-)
Let me apologize for a flipant late night post.... Sorry John - I got a little off track and a bit scappy - sorry. You have good thoughts on these things...had we been in person you would have seen me smiling more:-)
Best regards Jerry
uh...yeah...thats it... It was Inder who made all those remarks. (Thats the ticket!) :-) J On 3/14/11 12:38 PM, John MacAuley wrote:
No apologies needed. I didn't think you were being flippant and have not taken offence to anything yet. I have learned to call someone if I think i may be misinterpreting something. To me honest, I misread all the reply-to indents and thought Inder was asking the questions. It wasn't until your apology that I realized it was you :-)
Let me apologize for a flipant late night post.... Sorry John - I got a little off track and a bit scappy - sorry. You have good thoughts on these things...had we been in person you would have seen me smiling more:-)
Best regards Jerry
Hi Inder - see reponses in line. (and thanks for your patience with me:-) Jerry On 3/13/11 1:43 AM, Inder Monga wrote:
The <network>:<endpoint> tuple is analogous to the global IP address with its <network>/<host> definition. So we can call the NSI tuple a symbolic global addressing scheme. I think this is an important feature for NSI. AS it turns out, this tuple is sufficient to route a request across the global NSI topology, but is independent of the physical topology. It is the leaf NSA's job to know how to translate an NSI EPR to the local NRM. Indeed, since the leaf NSA is just a PA frontend to the NRM, we can say that translating from NSI EPR to local NRM is the job of the NRM-PA. THis makes the translation to local topology a function of the NRM and out of scope for NSI.
Please do not use EPR as a sub for STPs - it is already a standardized term..could cause confusion. http://en.wikipedia.org/wiki/WS-Addressing :)
Fair enough...there are just so many external documents I can't seem to keep our terminology sorted out from terms allowed or disallowed by other groups.
We could allow a topological specification as well. But this has the drawback that every application globally referencing that end point will need to know the topological location. If that physical location changes for any reason, all applications need to be changed. Just as IP address *can* be used for URLs, DNS names are used in order to abstract the desired endpoint from the physical location it occupies at the moment. In addition, advertising endpoints by their topological specification allows internal topology to leak out globally.
I understand what you are saying - but to me what you are suggesting falls within best practices and you cannot mandate someone not to encode topological spec into their local string. for example
3 te-1-4-ur03.santaclara.ca.sfba.comcast.net (68.86.248.17) 17.047 ms 18.316 ms 33.941 ms 4 te-1-10-0-5-ar01.sfsutro.ca.sfba.comcast.net (68.85.155.58) 62.206 ms 72.866 ms 52.751 ms 5 pos-1-7-0-0-cr01.sanjose.ca.ibone.comcast.net (68.86.90.153) 52.351 ms 72.093 ms 32.664 ms 6 pos-0-0-0-0-pe01.529bryant.ca.ibone.comcast.net
I just want to be sure you are not referring to encoding like the above which can be done?
I agree. The local domain has the prerogative to name an endpoint as they see fit. This is as you say a best practice issue. Likewise, since the local name is a local preference, then NSI as a standard should not expect or require the name to encode anything particular. i.e. From an NSI standpoint, the local name is just a string. NSI does not care what is encoded or not. In the example above, what you see are *names*. There is no expectation or requirement that all router interfaces will have such interface names or even that router interfaces will have names at all. Indeed, many don't even have IP addresses. Further, while these are "end points" in the formal sense, the ultimate user 'end points" rarely get named in this fashion (encoding interface information.) These names are fine as far as I am concerned because the automated agents are not relying on this infromation for anything. Given that the NSI tuple only encodes a globaly unique network name that is only used to link to the appropriate NSA, there should be an explicit NSI function/service that a) takes the network name and returns the NSA information, and b) takes the local name and returns other associated [topological] information. And vice versa. This is important in order to provide location independence, but should also be a fairly simple directory or lookup service. (This lookup service is how I expect local NRMs to convert a NSI reference to a local significance.)
I know Inder (and probably Tomohiro) have questions about how you select VLANs at a remote endpoint,
The question is how to specify aggregate end-points using this method of uninterpretable local strings. The number of these end-points when you consider virtual ones can be huge. So there is a benefit in having a specification that can aggregate those. The other question is how to show interconnectivity between two STPs - one in each domain. Second point first: I think the interconnectivity of two STPs is indicated in the topology DB. I.e //ESnet/Peer101==//NORDUnet/USxconnect01 As I see it, both networks will have to indicate the equivalent STP in the other network. This issue is a topology issue and a pathfinding issue, so it is an interesting and whorth while discussion, but I don't think it is something we need to resolve prior to V1.0.
First point: there is no primitive or notion formally in NSI that acts on an "aggregate end point"...What I think you mean is you want to specify that a connection can be terminated on any one VLAN in a specified set of VLANs. Right? So why do you want this (generaly)? Are you assuming that a tagged frame will be carried natively end to end across all intervening ethernet switches? The connection request primitive makes no such commitment. The "connection" service provided is neccessarilly a function of the payload definition at the ingress and egress. But this does not imply that the network must somehow provision VLANs natively in order to meet the service request. The network could easily just build a tunnel end to end with any technology available and put the frames in that tunnel. ... If the service carries the entire tagged frame as the payload, then any sane network provider would still tunnel it through another virtual connection to insulate itself from the effects of userville. The upshot is that the label set issues become just access framing issue - Its a local decision. Thus the RA can choose a VLAN as easily as the PA and without all the end-to-end hoohah. If the service just carries the payload section of the tagged frame, it gets even easier. If we change the primitive semantics of an "end point" to now be a "set of end points" we make things substantially more complex at this late stage for v1.0. We can perhaps find a means of specifying a label set (ala GMPLS), but for the standard, we need to think though how this is to function generally. Are we standardizing a special treatment for Ethernet VLANs? Or is this a more general treatment that will work for any subgroupings?? What are sub-groupings anyway? And are they a CS protocol issue or a topology/pathfinding issue? So - is this something the /primitive/ needs to deal with? or something the pathfinder should deal with? If either case, is this something that needs to be specified as something other than the tuple? (i.e. does the grouping need to be incorporated in the syntax of the reference, or is it a more substantial issue that should be reflected in the topology? There are probably several ways to accomplish this, but all have implications that are non-trivial...which makes me want to say push the discussion to post-V1.0 since user specified VLAN STPs will work, and we have little time to work through yet another change to the primitives, and get it all written up. I think we leave the semantics of the local name to the pathfinder as it will be the function that needs to map the name to local topological constructs. -->If a localname STP is mapped to a topological construct that represents a set of endpoints (e.g. an tagged port), then the pathfinder can recognize this and do the Right Thing. And the tuple reference is still sufficient to do this. The pathfinder is not our concern at this time. Further, I think these label set problems avoids the real issue: Flat VLANs suck horribly as an interdomain switching technology. So do raw wavelengths. These are not globally scalable (which is why QinQ was introduced and why PBB is now in vogue, and why MPLS works so well.) IMO, The primitives should [for now] require the RA specify the specific access tag STP at each end, and let the network PF decide how to drill tunnels and flip labels to deliver the payload. We should keep in mind also what the actual payload is: Is it the entire as-is ethernet frame? or is it the payload of the tagged frames? If it is the former, does that imply that we cannot tunnel it? If the latter, then changing VLANs inside the transport fraimg, is perfectly fine. We should consistently define the connection primitives to work in accordance with the NSI architectural concept of a "Connection" - not try to create a standardized workaround for limitations in certain possible transport technologies. Let the implementations (NRMs) deal with technology specific issues (e.g. mappng VLANs across the switches on the ground.), keep the standard to the high level model of a "Connection from A to B" We break our architectural abstractions whenever we address one particular technology specifically. I also believe we undermine the overall work if we try to stuff lots of Rube-Goldberg-esque mechanisms into the standard in order to make amends for fundamental limitations of a technology - particularly when we know these issues are likely to be resolved in the near future. (flat VLAN space is a perfect example).
but I view this as a pathfinding issue within each domain - not a global issue. While this is related to topology and visibility, if we stay within the confines/context of the NSI-CS protcol I do not think we need to address this in the standard. At least not immediately.
So whether we use a "urn:blah <domain>:<endpoint>" or just a raw tuple "//<domainname>/<endpointname>" is not a big issue with me. As long as we support the tuple and agree on *one* convention that all NSAs must recognize.
I prefer the urn representation (even though we could define our own string delimiter and format) and I imagine that OGF urn will be registered with IANA (http://tools.ietf.org/html/draft-dijkstra-urn-ogf-01 and http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xml)
Inder
I reiterate my support for OGF GID- the <networkname>:<localname> tuple for STP identification. Preferably without a URN prefix. If you to require that an endpoint identifier must be specified as a URN prefix, you are implying that the <networkname>:<localname> tuple is not sufficient to differentiate STPs for NSI purposes. What NSI requirement is not met by the simple tuple? These are good discussions to have - all of them. But I think we need to focus on the functionality we have and get that written and out as a spec. Best regards! Jerry
participants (8)
-
Chin Guok -
Evangelos Chaniotakis -
Inder Monga -
Jeff W. Boote -
Jeroen van der Ham -
Jerry Sobieski -
John MacAuley -
Tomohiro Kudoh