Subject: RE: CORRECTION: Last Call: CR-LDP Extensions for ASON to Informat ional

From: "Osama Aboul-Magd" <[email-masked]>
Date: Thu, 2 Jan 2003 19:06:14 -0500

Hi Adrian,

Those references are not included in the ITU document. Besides I am only
referencing drafts that already are WG documents and progressing at IETF.

Regards;

Osama Aboul-Magd

ATI Strategic Standards and Protocols

Nortel Networks

P.O. Box 3511, Station C

Ottawa, Ontario, Canada

K1Y-4H7

Tel: +1 613 763 5827

e.mail:[email-masked]

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Thursday, January 02, 2003 3:09 PM
To: Aboul-Magd, Osama [CAR:1A00:EXCH]; Ash, Gerald R (Jerry), ALASO;
[email-masked]
Cc: Atsushi Iwata; Norihito Fujita; Simon Marshall-Unitt; Lin, Zhi-Wei
(Zhi); [email-masked]; Shew, Stephen [SKY:QW33:EXCH]
Subject: Re: CORRECTION: Last Call: CR-LDP Extensions for ASON to
Informational

Hi Osama,

It would appear that your draft references several other drafts that are not
yet RFCs. Will you be removing these references?

Thanks,

Adrian

----- Original Message ----- 

From: Osama <mailto:[email-masked]>  Aboul-Magd 

To: Ash, Gerald R (Jerry), ALASO <mailto:[email-masked]>  ; [email-masked]
<mailto:[email-masked]>  

Cc: Adrian Farrel <mailto:[email-masked]>  ; Atsushi
<mailto:[email-masked]>  Iwata ; Norihito Fujita
<mailto:[email-masked]>  ; Simon <mailto:[email-masked]>
Marshall-Unitt ; Lin, <mailto:[email-masked]>  Zhi-Wei (Zhi) ;
[email-masked] <mailto:[email-masked]>  ; Stephen
<mailto:[email-masked]>  Shew 

Sent: Thursday, January 02, 2003 1:24 PM

Subject: RE: CORRECTION: Last Call: CR-LDP Extensions for ASON to
Informational

Hi Gerry, 

This draft is not entirely about crankback. It only reflects agreements
reached at the ITU. 

I'd be very happy referencing your draft have it been an RFC. Unfortunately
ITU rules don't allow the referencing of work that is still in progress.

Regards; 

Osama Aboul-Magd 
ATI Strategic Standards and Protocols 
Nortel Networks 
P.O. Box 3511, Station C 
Ottawa, Ontario, Canada 
K1Y-4H7 
Tel: +1 613 763 5827 
e.mail:[email-masked] <mailto:e.mail:[email-masked]>  

-----Original Message----- 
From: Ash, Gerald R (Jerry), ALASO [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, January 02, 2003 1:16 PM 
To: [email-masked] <mailto:[email-masked]>  
Cc: Ash, Gerald R (Jerry), ALASO; Adrian Farrel; Atsushi Iwata; Norihito
Fujita; Simon Marshall-Unitt; Lin, Zhi-Wei (Zhi); Aboul-Magd, Osama
[CAR:1A00:EXCH]; [email-masked] <mailto:[email-masked]> 

Subject: RE: CORRECTION: Last Call: CR-LDP Extensions for ASON to
Informational 

A crankback TLV is suggested in Section 4.3.  While crankback is a desirable
extension to both CR-LDP and RSVP-TE (and required by ASON), the proposal
ignores the prior work done in
http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-04.txt
<http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-04.txt> .
The advantages of the proposed method should be identified and justified.  

Furthermore, crankback is not yet within the charter of any IETF Working
Group, although this has been proposed (e.g., the IETF-54/CCAMP minutes
state 'The charter update is way overdue. Items may be added -
protection/restoration, crankback and multi-area operations'). It seems
inappropriate to specify a particular crankback extension independent of the
possible future work of an IETF Working Group.

Jerry Ash 

-----Original Message----- 
From: The IESG [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, December 31, 2002 12:40 PM 
Subject: CORRECTION: Last Call: CR-LDP Extensions for ASON to 
Informational 

**PLEASE NOTE THIS IS A TWO WEEK LAST CALL.** 

The IESG has received a request to consider CR-LDP Extensions for ASON 
<draft-aboulmagd-ccamp-crldp-ason-ext-02.txt> as an Informational RFC.  
This has been reviewed in the IETF but is not the product of an IETF 
Working Group. 

The IESG plans to make a decision in the next few weeks, and solicits 
final comments on this action.  Please send any comments to the 
[email-masked] or [email-masked] mailing lists by 2003-1-15. 

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-aboulmagd-ccamp-crldp-ason-ext-02.
txt
<http://www.ietf.org/internet-drafts/draft-aboulmagd-ccamp-crldp-ason-ext-02
.txt>

---

From: John Drake <[email-masked]>
Date: Thu, 9 Jan 2003 16:19:13 -0800

Gerry,

I share your concerns.

I skimmed the informational RFCs you cited and they don't look much like
requirements documents.  Rather, they look like ITU protocol enhancements to
IETF protocols.  Quoting from the abstracts:  "It proposes additional
extensions to these signaling protocols to support the capabilities of an
ASON network." and "This document describes Constraint Route Label
Distribution Protocol (CR-LDP) extensions for use across ASON reference
points."

Using your example that it would be ill-considered for the IETF to develop
its own version of G.709, I think it would be better if ASON requirements
were brought into CCAMP and worked on there.

Thanks,

John 

-----Original Message-----
From: Ash, Gerald R (Jerry), ALASO [mailto:[email-masked]]
Sent: Thursday, January 09, 2003 2:47 PM
To: Lin, Zhi-Wei (Zhi)
Cc: Ash, Gerald R (Jerry), ALASO; [email-masked]; Osama Aboul-Magd;
[email-masked]; Lam, Hing-Kam (Kam); Lazer, Monica A, ALASO; Varma, Eve L
(Eve); Stephen Shew (E-mail); Alan McGuire (E-mail); Brungard, Deborah
A, ALASO; Loa Andersson; Adrian Farrel; Stephen Trowbridge; Lazer,
Monica A, ALASO
Subject: RE: CORRECTION: Last Call: CR-LDP Extensions for ASON to
Informational

Zhi,

> In terms of where the liaisons are, not sure. I checked the 
> link as well, and couldn't find any of the liaisons that was 
> sent from ITU-T Q.14/15 to IETF CCAMP WG.

Thanks to Kam for showing us the linkage, it's rather complicated...  Maybe
that's why we've seen no discussion in CCAMP on these ASON Signaling
Recommendations [G.7713.2 (GMPLS RSVP-TE) and G.7713.3 (GMPLS CR-LDP)].
Hopefully folks will look at them and provide comments.
 
> In terms of the intentions of the draft Recommendations 
> G.7713.x series, these draft Recommendations are targeted to 
> support the ASON control plane network. There is a difference 
> between what IETF is working on and what ITU is working on, 
> and these are mainly targeted for large incumbent carriers 
> such as your company (and many of these requirements are 
> driven by large carriers). 

So I guess you're saying that the G.7713.x Recommendations are actually
'requirements', presumably to be considered by the IETF for GMPLS
extensions.  Is that also the purpose of yours and Osama's Informational
RFCs on 'GMPLS extensions for ASON'?  That is,
http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rsvpte-04.txt
and
http://www.ietf.org/internet-drafts/draft-aboulmagd-ccamp-crldp-ason-ext-02.
txt are actually GMPLS requirements for CCAMP to consider, is that right?

BTW, 'large carriers' (and medium and small carriers, too) are providing
requirements/needs directly into the GMPLS effort in IETF, as well as
indirectly through the ITU.

> For example, one obvious 
> difference is the support of only IP addressing within the 
> GMPLS. In the ITU ASON extensions, the G.7713.x protocols 
> include support for not only the IP addresses, but also NSAP 
> addresses.
> 
> Another obvious difference is that when ITU was developing 
> ASON and IETF developing GMPLS, there was a position within 
> CCAMP (during GMPLS development) that there is an inherent 
> sharing of information between a user of the network and the 
> network itself (the overlay vs. peer discussion). The ITU has 
> always taken the approach that we need to support a range of 
> information sharing, from fully sharing info (the I-NNI 
> interface) to flexible info sharing (the E-NNI interface) to 
> no sharing of info (the UNI interface). The majority of the 
> extensions (NOTE these are extensions and not competing 
> protocols) are to support these fundamental network design decisions.
> 
> Another example of the difference in design philosophy is in 
> the area of routing. Within the CCAMP, routing extensions are 
> made to the existing protocols to support additional link 
> attributes for GMPLS. However, the concept of multiple 
> domains and hierarchies are not really provided (not beyond 
> what the existing protocol provides). These concepts (domains 
> and hierarchies) are again driven by the large carriers (such 
> as AT&T and BT). What we (as ITU-T participants) did were to 
> listen to these requirements and added extensions that 
> supports the carriers' requirements.

First, I think there is confusion in terminology across the various
standards bodies.  For example, and quoting from Deborah Brungard: "One key
item is the confusion between OIF, IETF, ITU participants on the definition
of inter-domain interface. In ITU terminology, inter-domain is between
carriers (and as an option for the carrier to use within his domain).
Inter-domain is based on reachability, no topology sharing. Also no
hierarchy. G.8080 is very clear on this. For OIF, an inter-domain interface
is between vendors islands i.e. OIF is an interop forum. For IETF, it's
interior (e.g. GMPLS/OSPF) and exterior (e.g. BGP)."

Second, we should align the ITU and IETF 'GMPLS' efforts.  That is, we need
to a) understand the terminology, and b) provide the requirements from ITU
to IETF (as you are doing through your informational RFCs).

> In terms of your question about interoperability, the 
> protocol extensions from the ITU is designed as 
> optional/additional "tools" as part of the GMPLS toolkit. If 
> a vendor chooses to support the ITU's ASON application, they 
> will implement. Otherwise they will only implement the core 
> GMPLS and no more. Which vendor decides to implement what 
> really depends on what carriers (such as your company) are 
> going to ask for. The carriers have set the requirements in 
> ITU and those requirements have driven the protocol 
> extensions. The protocol design within the IETF were driven 
> from a different direction (or a different set of companies 
> -- more the enterprise customers).

You're suggesting that a common set of requirements is driving the G.7713.x
series, maybe so, but then why does CR-LDP have crankback and RSVP-TE
doesn't have crankback (as one example of inconsistencies)?  Also, I'm not
sure it's a great approach for vendors to decide which 'GMPLS extensions' to
implement based on 2 versions of GMPLS (IETF and ITU), and also based on
what operators ask for (it still sounds like we're getting 2 versions of
GMPLS).

> Hope this answers your questions and concerns, and hope 
> others will chime in with their opinion on this...

Yes, I hope others will comment on this thread.

Thanks,
Jerry

> Zhi
> From: Ash, Gerald R (Jerry), ALASO [mailto:[email-masked]]
> Sent: Wednesday, January 08, 2003 3:48 PM
> To: Loa Andersson; Adrian Farrel
> Cc: Ash, Gerald R (Jerry), ALASO; [email-masked]; Osama Aboul-Magd;
> [email-masked]; Lin, Zhi-Wei (Zhi); [email-masked]
> Adrian> I am saying that it sounds to me from the discussion that 
> Adrian> the ITU has not yet reached consent. It seemed to me that 
> Adrian> if the draft is intended to document the ITU preferences as 
> Adrian> informational, it would be as well to wait until the ITU has
> Adrian> fully signed off. I don't see any rush for this.
> 
> Loa> ok - I can see the difference - and it seems that you are correct. If
> Loa> the ITU discussion still has some way to go before the discussion
> Loa> settles and the preferences better known - wouldn't it be 
> Loa> appropriate to wait until this happens?
> 
> ASON Signaling Recommendations G.7713.2 (GMPLS RSVP-TE) and 
> G.7713.3 (GMPLS CR-LDP) are proposed for consent at the 
> upcoming SG15 meeting, 20-31 January (Geneva).  A Liaison was 
> sent to the IETF containing Recommendation text, but I can't 
> find it on http://www.ietf.org/IESG/LIAISON/.
> 
> Both documents propose detailed protocol specifications 
> including new TLVs (e.g., crankback TLV in G.7713.3).  The 
> intent of these Recommendations is unclear.  
> 
> If these are statements of 'ITU preferences/requirements' 
> which are made known to the IETF through the Informational 
> RFCs, such as Osama's and Zhi's, then fine.  IETF can then 
> take up the 'preferences/requirements' and consider them for 
> upgrading RSVP-TE and CR-LDP protocols (although CR-LDP is capped).  
> 
> However, if they are intended as alternative protocol specs 
> competing with the IETF specs, then that's a problem.  Which 
> spec does a vendor implement and an operator use, given 
> interoperability needs, etc.?  It would be analogous to the 
> IETF specifying their version of G.709.
> 
> A clarification of the intent of these Recs. would be helpful.
> 
> Jerry Ash
>

---

From: John Drake <[email-masked]>
Date: Thu, 9 Jan 2003 16:19:13 -0800

Gerry,

I share your concerns.

Thanks,

John 

-----Original Message-----
From: Ash, Gerald R (Jerry), ALASO [mailto:[email-masked]]
Sent: Thursday, January 09, 2003 2:47 PM
To: Lin, Zhi-Wei (Zhi)
Cc: Ash, Gerald R (Jerry), ALASO; [email-masked]; Osama Aboul-Magd;

Zhi,

 

Thanks,
Jerry

---

From: "Osama Aboul-Magd" <[email-masked]>
Date: Wed, 8 Jan 2003 12:31:23 -0500

Loa,

I've just sent a response to Adrian. ITU is scheduled to consent this draft
at the end of the month. Therefore this draft is very urgent.

Regards;

Osama Aboul-Magd

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Wednesday, January 08, 2003 12:23 PM
To: Adrian Farrel
Cc: [email-masked]; Aboul-Magd, Osama [CAR:1A00:EXCH]; [email-masked]
Subject: Re: CORRECTION: Last Call: CR-LDP Extensions for ASON to
Informational

Adrian,

Adrian Farrel wrote:
>>trying to understand what you are saying - it seems like you are
>>implying that there is no consensus with in ITU on how to progress
>>this, and that therefore would be premature for IETF to publish
>>this as an informational RFC. Correct?
> 
> 
> I'm not quite saying that.
> I am saying that it sounds to me from the discussion that the ITU has not
yet
> reached consent. It seemed to me that if the draft is intended to document
the
> ITU preferences as informational, it would be as well to wait until the
ITU has
> fully signed off. I don't see any rush for this.

ok - I can see the difference - and it seems that you are correct. If
the ITU discussion still has some way to go before the discussion
settles and the preferences better known - wouldn't it be appropriate to 
wait until this happens?

Osama, care to comment?

/Loa

> 
> 
>>Anyhow - I think it would be appropriate to add a note clarifying that
>>IETF will not progress cr-ldp beyond Proposed Standard.
> 
> 
> Adrian
> 
> 
> 
> 

-- 
Loa Andersson

Mobile          +46 739 81 21 64
Email           [email-masked]

---

From: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
Date: Wed, 8 Jan 2003 16:18:59 -0500

Hi Gerry,

Happy new year.

In terms of where the liaisons are, not sure. I checked the link as well, and couldn't find any of the liaisons that was sent from ITU-T Q.14/15 to IETF CCAMP WG.

In terms of the intentions of the draft Recommendations G.7713.x series, these draft Recommendations are targetted to support the ASON control plane network. There is a difference between what IETF is working on and what ITU is working on, and these are mainly targeted for large incumbent carriers such as your company (and many of these requirements are driven by large carriers). For example, one obvious difference is the support of only IP addressing within the GMPLS. In the ITU ASON extensions, the G.7713.x protocols include support for not only the IP addresses, but also NSAP addresses.

Another obvious difference is that when ITU was developing ASON and IETF developing GMPLS, there was a position within CCAMP (during GMPLS development) that there is an inherent sharing of information between a user of the network and the network itself (the overlay vs. peer discussion). The ITU has always taken the approach that we need to support a range of information sharing, from fully sharing info (the I-NNI interface) to flexible info sharing (the E-NNI interface) to no sharing of info (the UNI interface). The majority of the extensions (NOTE these are extensions and not competing protocols) are to support these fundamental network design decisions.

Another example of the difference in design philosophy is in the area of routing. Within the CCAMP, routing extensions are made to the existing protocols to support additional link attributes for GMPLS. However, the concept of multiple domains and hierarchies are not really provided (not beyond what the existing protocol provides). These concepts (domains and hierarchies) are again driven by the large carriers (such as AT&T and BT). What we (as ITU-T participants) did were to listen to these requirements and added extensions that supports the carriers' requirements.

In terms of your question about interoperability, the protocol extensions from the ITU is designed as optional/additional "tools" as part of the GMPLS toolkit. If a vendor chooses to support the ITU's ASON application, they will implement. Otherwise they will only implement the core GMPLS and no more. Which vendor decides to implement what really depends on what carriers (such as your company) are going to ask for. The carriers have set the requirements in ITU and those requirements have driven the protocol extensions. The protocol design within the IETF were driven from a different direction (or a different set of companies -- more the enterprise customers).

Hope this answers your questions and concerns, and hope others will chime in with their opinion on this...

Zhi

-----Original Message-----
From: Ash, Gerald R (Jerry), ALASO [mailto:[email-masked]]
Sent: Wednesday, January 08, 2003 3:48 PM
To: Loa Andersson; Adrian Farrel
Cc: Ash, Gerald R (Jerry), ALASO; [email-masked]; Osama Aboul-Magd;

ASON Signaling Recommendations G.7713.2 (GMPLS RSVP-TE) and G.7713.3 (GMPLS CR-LDP) are proposed for consent at the upcoming SG15 meeting, 20-31 January (Geneva).  A Liaison was sent to the IETF containing Recommendation text, but I can't find it on http://www.ietf.org/IESG/LIAISON/.

Both documents propose detailed protocol specifications including new TLVs (e.g., crankback TLV in G.7713.3).  The intent of these Recommendations is unclear.  

If these are statements of 'ITU preferences/requirements' which are made known to the IETF through the Informational RFCs, such as Osama's and Zhi's, then fine.  IETF can then take up the 'preferences/requirements' and consider them for upgrading RSVP-TE and CR-LDP protocols (although CR-LDP is capped).  

However, if they are intended as alternative protocol specs competing with the IETF specs, then that's a problem.  Which spec does a vendor implement and an operator use, given interoperability needs, etc.?  It would be analogous to the IETF specifying their version of G.709.

Jerry Ash